Typesense Search Canary That Fails on Zero Results

The worst search outage is the quiet one: the cluster answers, the storefront renders, and every query returns nothing. This blueprint is a canary for exactly that failure. io.kestra.plugin.typesense.Search runs a query a real customer would type, running shoes, across name,description,brand. If totalHits comes back zero, an If task pages Slack and fails the execution through io.kestra.plugin.core.execution.Fail, turning a silent relevance outage into a red execution and an alert within 15 minutes.

How it works

1. canary_search (io.kestra.plugin.typesense.Search) sends the query with queryBy: name,description,brand against the products collection. The task exposes {{ outputs.canary_search.totalHits }} as a scalar and stores the full result set in internal storage at {{ outputs.canary_search.uri }}.
2. gate (io.kestra.plugin.core.flow.If) checks totalHits == 0. On zero hits it posts a Slack alert naming the query, then fail_canary (io.kestra.plugin.core.execution.Fail) marks the execution failed so dashboards and SLA checks see an incident, not a green run with a scary log line.
3. log_healthy records the hit count on healthy runs, so the execution history becomes a baseline; a slow drift from 40 hits to 3 is visible before it reaches zero.
4. The errors block sends a distinct Slack alert when the canary itself cannot run, which usually means the cluster is unreachable or the API key expired.
5. A disabled-by-default Schedule trigger runs the probe every 15 minutes.

The connection uses the Typesense default port 8108 as a plain value and https: false for a local or private-network cluster; set https: true when your production cluster terminates TLS.

What you get

• A relevance probe that distinguishes three states: healthy, zero results, and cluster down.
• A failed execution on zero hits, so the incident shows up everywhere failed executions already do.
• A logged hit-count baseline on every healthy run.
• A pattern that scales to a battery of canary queries by duplicating one task.

Who it's for

• E-commerce teams whose revenue depends on the search bar returning products.
• Search engineers who want an alarm on relevance, not only on cluster uptime.
• SREs adding search to the set of user journeys covered by synthetic checks.

Why orchestrate this with Kestra

A canary is only useful if something acts on it. Kestra gives the probe a schedule, a decision (If), an escalation (Slack), and a state change (Fail) in one auditable flow. The execution history doubles as the canary's own uptime record, and extending the probe from one query to twenty is YAML duplication, not new infrastructure.

Prerequisites

• A running Typesense cluster with a populated products collection; the nightly catalog index blueprint sets one up.
• A canary query that should always match your catalog; replace running shoes with yours.
• A Slack incoming webhook for alerts.

Secrets

• TYPESENSE_HOST: hostname or IP of the Typesense node or load balancer.
• TYPESENSE_API_KEY: an API key with search access to the collection.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add the three secrets to your Kestra namespace.
2. Execute the flow against a populated collection and confirm the healthy log line reports a nonzero hit count.
3. Temporarily change query to gibberish and execute again to see the Slack alert and the failed execution.
4. Restore your real canary query and set disabled: false on the every_15_minutes trigger.

How to extend

• Duplicate canary_search for your top five storefront queries and gate on each.
• Tighten the gate from == 0 to a minimum expected hit count per query.
• Add a filter such as in_stock:true so the canary measures what customers can actually buy.
• Chain this flow after the nightly rebuild so every reindex is followed immediately by a relevance check.

Links

• Typesense plugin documentation
• Typesense documentation