Weekly Metaplane Monitor Inventory Digest

Monitor coverage erodes quietly. Someone disables a noisy monitor during an incident and forgets to re-enable it; new tables land without anyone extending coverage; a connection gets rebuilt and half its monitors do not come back. This blueprint makes the erosion visible with io.kestra.plugin.metaplane.List: every week it fetches the complete monitor inventory of a connection, disabled monitors included, and posts the headcount to Slack. A number that drifts down between digests is a coverage regression someone can chase before it matters.

How it works

1. list_monitors (io.kestra.plugin.metaplane.List) calls the Metaplane API for every monitor on the connectionId. includeDisabled: true counts monitors that exist but do not run, exactly the ones that erode coverage invisibly.
2. fetchType: FETCH returns the monitors directly as task outputs, an array of monitor objects plus a total count. The alternatives are FETCH_ONE for a single monitor, STORE to write the list to internal storage as a file for large inventories, and NONE.
3. post_digest posts the scalar total to Slack with the connection ID, keeping the message a one-line weekly heartbeat.
4. The errors block raises a distinct alert when the inventory itself cannot run, since a missing digest is easy to overlook on a busy Monday.
5. A disabled-by-default Schedule trigger posts every Monday at 08:00, before the weekly data team sync.

What you get

• A weekly coverage heartbeat, one number whose week-over-week movement tells the story.
• Disabled monitors counted, surfacing the incident-time toggles nobody remembered to revert.
• The full monitor list in every execution's outputs, ready for inspection when the count moves.
• An auditable history of coverage over time in Kestra's execution log.

Who it's for

• Data platform leads accountable for observability coverage across a growing warehouse.
• Teams who tune monitors during incidents and want a safety net for forgotten toggles.
• Anyone preparing a data quality review who needs the current inventory on demand.

Why orchestrate this with Kestra

An inventory that someone must remember to check is not an inventory, it is a hope. Kestra runs the audit on cadence, keeps every result in the execution history so trends are reconstructable, alerts when the audit itself breaks, and turns the monitor list into structured outputs that downstream tasks can diff, filter, or store. The same flow doubles as an on-demand lookup by executing it manually with a different connection ID.

Prerequisites

• A Metaplane workspace and the UUID of the connection to inventory.
• A Metaplane API token.
• A Slack incoming webhook for the digest.

Secrets

• METAPLANE_API_TOKEN: Metaplane API token.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add both secrets to your Kestra namespace.
2. Set the connection_id input default to a connection UUID from your Metaplane settings.
3. Execute the flow and confirm the Slack digest reports the expected monitor count.
4. Enable the weekly_digest trigger.

How to extend

• Duplicate the List task per connection to cover several warehouses in one digest.
• Switch to fetchType: STORE for very large inventories and process the stored ion file downstream.
• Persist each week's total in Kestra's KV store and alert only when the count drops, turning the digest into a regression detector.
• Set fetchGroups: true to include monitor group information when your workspace organizes monitors into groups.

Links

• Metaplane plugin documentation
• Metaplane documentation