Meilisearch Search Canary Catching Silent Index Wipes

A search index can be empty and still return HTTP 200. Health checks pass, dashboards stay green, and users quietly get zero results until someone notices. This blueprint closes that gap with a canary: io.kestra.plugin.meilisearch.Search runs a query that must always match in a healthy docs index, and an If task inspects the totalHits output. Zero hits sends a Slack alert with the exact query and then fails the execution through io.kestra.plugin.core.execution.Fail, so the incident is visible both in chat and in every dashboard built on execution state.

How it works

1. probe_search (io.kestra.plugin.meilisearch.Search) runs the canary_query input against the docs_site index. The task exposes the hit count as {{ outputs.probe_search.totalHits }} and stores the full result set as a file at {{ outputs.probe_search.uri }}.
2. check_hits (io.kestra.plugin.core.flow.If) evaluates totalHits == 0.
3. On zero hits, alert_zero_hits posts the query and index name to Slack, then fail_execution fails the run with a precise error message.
4. On a healthy count, log_healthy records the number of hits, turning the execution history into an availability log.
5. The errors block posts to Discord when the execution goes red for any reason, including an unreachable Meilisearch instance, so content alerts and platform alerts land in separate channels.
6. A disabled-by-default Schedule trigger probes every 15 minutes.

What you get

• Detection of silent index wipes, broken ingest pipelines, and misconfigured indexes within minutes.
• A deliberate execution failure on zero hits, so search health shows up in Kestra dashboards and SLA reports.
• Separate channels for content-facing alerts (Slack) and platform failures (Discord).
• A one-input design: change the canary query without touching the flow.

Who it's for

• Platform teams operating Meilisearch behind documentation or content sites.
• Content teams who found out about their last search outage from a user.
• Anyone running an ingest pipeline who wants an independent check that the index it feeds still answers.

Why orchestrate this with Kestra

A canary is only useful if it runs relentlessly and complains loudly. Kestra provides the schedule, the conditional branching on the hit count, the deliberate failure semantics, and the execution history that turns every probe into an auditable data point, all in declarative YAML with no monitoring agent to deploy.

Prerequisites

• A running Meilisearch instance with a populated docs_site index, for example from the docs site ingest blueprint.
• A Slack incoming webhook for zero-hit alerts and a Discord webhook for failure paging.

Secrets

• MEILISEARCH_URL: Meilisearch connection URL, e.g. https://meilisearch.internal:7700.
• MEILISEARCH_KEY: Meilisearch API key with search permissions.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.
• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.

Quick start

1. Add the four secrets to your Kestra namespace.
2. Set canary_query to a term that appears on evergreen pages of your docs.
3. Execute the flow once and confirm the healthy log line shows a nonzero hit count.
4. Set disabled: false on the every_15_minutes trigger.

How to extend

• Add a minimum hit threshold instead of zero by changing the If condition, catching partial index loss as well.
• Probe several indexes by wrapping the search in a ForEach over index names.
• Route the zero-hit branch into an automatic reindex by calling the index rebuild pipeline blueprint with a Subflow task.
• Track hit counts over time by writing totalHits to the KV store after each probe.

Links

• Meilisearch plugin documentation
• Meilisearch documentation