Weekly Meilisearch Facet Report on Documentation Sections

Content teams rarely know what their documentation corpus actually contains. Pages accumulate, sections grow unevenly, and nobody looks until search feels off. This blueprint turns Meilisearch's facet search into a recurring inventory report: io.kestra.plugin.meilisearch.FacetSearch queries the section facet of the docs index, filtered to published pages, and a Slack digest carries the facet hit count every Monday morning. The full facet breakdown is stored as a file on the execution for anyone who wants the details.

How it works

1. facet_report (io.kestra.plugin.meilisearch.FacetSearch) searches the section facet of the docs_site index with the facet_query input and a filters entry restricting results to status = published. The task exposes the number of matching facet values as {{ outputs.facet_report.totalHits }} and the full facet result set as a file at {{ outputs.facet_report.uri }}.
2. send_digest posts the scalar count and the query to Slack, pointing readers at the execution for the complete breakdown.
3. The errors block posts a distinct Slack alert on failure, with the most common cause named directly: the facet attribute is not configured as filterable.
4. A disabled-by-default Schedule trigger sends the digest every Monday at 08:00.

What you get

• A recurring, zero-effort answer to the question of what the docs corpus contains, by section.
• Scalar counts in the Slack payload, safe to interpolate into JSON, with the full result attached as a file.
• A filters example showing how to scope facet reports to published content only.
• A one-input design: repoint the report at another section family by changing facet_query.

Who it's for

• Documentation leads planning where to invest writing effort next.
• Content teams tracking how sections grow or shrink release over release.
• Search operators verifying that faceting behaves as configured in production.

Why orchestrate this with Kestra

A facet query is one API call, but a report is a habit: it needs a schedule, a place where the full results live, a message where the team already reads, and an alert when the query breaks. Kestra provides all four in a two-task flow, and the execution history becomes a weekly time series of corpus snapshots for free.

Prerequisites

• A Meilisearch index with a section attribute declared as filterable, populated for example by the docs site ingest blueprint.
• Documents carrying a status field if you keep the published filter, or remove the filters entry.
• A Slack incoming webhook for the digest and failure alerts.

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.

Quick start

1. Add the three secrets to your Kestra namespace.
2. Declare section and status as filterable attributes on your index.
3. Execute the flow and check the Slack digest plus the stored facet file in the execution's Outputs tab.
4. Set disabled: false on the weekly trigger.

How to extend

• Run several facet reports in one flow with a ForEach over facet names such as section, product, and version.
• Parse the stored facet file with a Python task to include the top section names and counts in the digest text.
• Compare this week's count against last week's by storing it in the KV store and alerting on large drops.
• Pair the report with the zero-result queries review blueprint to contrast what the corpus has with what users cannot find.

Links

• Meilisearch plugin documentation
• Meilisearch documentation