Hourly Health Probe on a Critical Metaplane Monitor

Some tables matter more than the rest, the one feeding the billing job, the executive dashboard, the ML feature store. This blueprint gives one such monitor its own heartbeat. Every hour, io.kestra.plugin.metaplane.Get reads the monitor's latest result without triggering a new run, and the flow converts that status into an execution state: FAIL or ERROR pages Slack and then deliberately fails the execution, so anything watching execution states, SLA dashboards, dependent flows, alert rules, sees red. PASS and the in-training states leave a one-line log, turning the execution history into an hourly health record.

How it works

1. probe (io.kestra.plugin.metaplane.Get) fetches the monitor's most recent result and exposes status, monitorId, and checkedAt as scalar outputs, plus a series array with per-series values, bounds, and open related incidents.
2. route_health (io.kestra.plugin.core.flow.If) treats only FAIL and ERROR as incidents. IN_TRAINING, NOT_ENOUGH_DATA, and other inconclusive statuses pass quietly, so a freshly created monitor never pages anyone.
3. On an incident, page_slack posts the status and check timestamp first, then fail_execution (io.kestra.plugin.core.execution.Fail) fails the execution with a message naming the monitor and status.
4. On a healthy probe, log_healthy writes the status and timestamp to the execution log.
5. The errors block posts to Slack on any failed execution, which covers both the deliberate failure and a probe that could not reach the API; in both cases the critical table needs attention.

What you get

• Monitor health translated into the one signal every tool understands, execution success or failure.
• Read-only probing, Get never triggers monitor runs, so hourly probes cost nothing on the Metaplane side.
• Immunity to in-training noise, only FAIL and ERROR page.
• An hourly health log of the critical table for free in the execution history.

Who it's for

• Teams with one or two tables whose degradation is an incident, not a ticket.
• Platform engineers wiring data health into SLA dashboards that already watch Kestra execution states.
• On-call rotations that want Slack pages backed by an auditable probe history.

Why orchestrate this with Kestra

Metaplane holds the verdict; Kestra makes it operational. By mapping monitor status onto execution state, every tool already integrated with Kestra, dependency conditions, alerting on failed executions, SLA reporting, inherits data quality awareness without new integrations. The If task keeps the incident policy declarative and reviewable, and changing what counts as an incident is a one-line edit.

Prerequisites

• A Metaplane workspace and the UUID of the business-critical monitor.
• A Metaplane API token.
• A Slack incoming webhook for pages.

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. Replace the placeholder monitorId with the UUID of your critical monitor.
3. Execute the flow manually; a healthy monitor logs its status, a degraded one pages Slack and fails the execution.
4. Enable the hourly_probe trigger.

How to extend

• Add UNKNOWN to the incident condition when a monitor that cannot report is as alarming as one that fails.
• Make dependent flows wait on this one with a flow trigger conditioned on SUCCESS, so downstream jobs pause automatically while the critical table is degraded.
• Probe several critical monitors by looping with io.kestra.plugin.core.flow.ForEach over a list of monitor IDs.
• Prefer push over poll for faster reaction, the Metaplane monitor result reactor blueprint fires on status changes instead of a fixed schedule.

Links

• Metaplane plugin documentation
• Metaplane documentation