React to Metaplane Monitor Status Changes

Most alerting either spams on every check or stays quiet until someone looks. This blueprint does neither. io.kestra.plugin.metaplane.MonitorResultTrigger polls one monitor on an interval and fires an execution only when the status differs from the previous check, the first evaluation just establishes the baseline. A flip to FAIL or ERROR pages Discord within the polling interval; a flip back to PASS posts a recovery note so nobody keeps investigating a resolved issue. Between changes, the trigger produces no executions at all.

How it works

1. on_status_change (io.kestra.plugin.metaplane.MonitorResultTrigger) polls the monitor every five minutes (interval: PT5M). It compares each result against the previous one and fires only on a change; a monitor that stays PASS, or even stays FAIL, generates nothing.
2. When the trigger fires, it hands the flow three scalar outputs, trigger.status, trigger.monitorId, and trigger.checkedAt, the status at the moment of change, the monitor it belongs to, and when the monitor last ran.
3. route_status (io.kestra.plugin.core.flow.If) branches on the new status. PASS means the monitor just recovered from something worse; anything else, FAIL, ERROR, UNKNOWN, or an in-training state, means it just degraded.
4. Each branch posts its own Discord message, a recovery note or a triage page with the check timestamp.
5. The errors block alerts when the reaction flow itself breaks, because a dead webhook must not convert a status change into silence.

What you get

• Edge-triggered alerting, one message per transition instead of one per check, with recoveries announced as clearly as failures.
• Detection latency bounded by the polling interval, five minutes by default.
• Zero execution cost while the monitor is stable, no matter how long that lasts.
• A full audit trail, every status transition of the monitor becomes an execution in Kestra's history.

Who it's for

• On-call data engineers who want to hear about transitions, not steady states.
• Teams whose Metaplane alerts go to email while their triage happens in Discord.
• Anyone building automated remediation, the trigger is the entry point and the Discord tasks are placeholders for real reactions.

Why orchestrate this with Kestra

A status change is an event, and events deserve workflows, not just notifications. Putting the reaction in Kestra means the response can grow from a Discord message into anything the platform runs, quarantine a table, re-run an upstream load, open a ticket, all versioned in the same flow and all traceable to the exact transition that caused them. The trigger keeps state between polls, so the change detection needs no external storage.

Prerequisites

• A Metaplane workspace and the UUID of the monitor to watch.
• A Metaplane API token.
• A Discord incoming webhook for pages and recovery notes.

Secrets

• METAPLANE_API_TOKEN: Metaplane API token.
• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.

Quick start

1. Add both secrets to your Kestra namespace.
2. Replace the placeholder monitorId with a UUID from your Metaplane workspace.
3. Set disabled: false on the trigger; the first poll establishes the baseline without firing.
4. Watch the next real status change arrive in Discord within five minutes of the monitor run.

How to extend

• Duplicate the trigger with different monitor IDs to watch several monitors from one flow, each trigger keeps its own baseline.
• Replace the degradation branch with real remediation, re-run the upstream load with a subflow, or gate downstream publishes with the Metaplane quality gate blueprint.
• Tighten interval for critical monitors or relax it for noisy ones to balance latency against API calls.
• Fetch full context on degradation with io.kestra.plugin.metaplane.Get before paging, as shown in the incident context fetch blueprint.

Links

• Metaplane plugin documentation
• Metaplane documentation