Fetch Metaplane Context When a Page Fires

The first minutes of an incident are spent gathering context, which monitor fired, what does it say, when did it last run. This blueprint automates that gathering. The pager's webhook action calls a Kestra webhook with the monitor ID in the body; io.kestra.plugin.metaplane.Get fetches the monitor's latest result; and the incident channel receives a briefing with the status and check timestamp before the responder has finished acknowledging the page. The full per-series detail, values, bounds, and open related incidents, lands in the execution outputs for the deep dive.

How it works

1. pager_webhook (io.kestra.plugin.core.trigger.Webhook) exposes an endpoint keyed by a URL secret. Point the pager's webhook action at it with a JSON body containing monitorId.
2. fetch_context (io.kestra.plugin.metaplane.Get) reads the monitor's latest result. The monitor ID comes from trigger.body.monitorId when the webhook fired, with the monitor_id input as a fallback so the flow also runs manually during drills.
3. Get is read-only, it fetches the most recent result without triggering a new monitor run, so context arrives in seconds even when the warehouse is struggling.
4. post_summary posts the scalar outputs, monitorId, status, and checkedAt, to the incident channel; the series array with values, bounds, and open related incidents stays in the execution outputs.
5. The errors block alerts a separate ops channel on Discord when context fetching itself fails, telling the responder to open Metaplane directly instead of waiting for a briefing that will not come.

What you get

• Triage that starts with facts, the status and its timestamp are in the channel before the responder opens a laptop.
• A read-only fetch that adds zero load to the monitored warehouse.
• Manual drill support, run the flow with any monitor ID to rehearse the incident path.
• Every page and its context preserved as an execution, ready for the postmortem timeline.

Who it's for

• On-call data engineers paged by PagerDuty, Opsgenie, or any tool with a webhook action.
• Incident commanders who want context posted where the response happens, not locked in the pager UI.
• Teams measuring time-to-triage who want the context-gathering minutes back.

Why orchestrate this with Kestra

Pagers are good at waking people and bad at briefing them. Kestra sits between the page and the responder, receives the event, enriches it against the Metaplane API, and delivers the briefing to the channel where triage happens. Because the enrichment is a flow, it can grow, add warehouse queries, recent execution lookups, or runbook links, without touching the pager configuration, and every invocation is auditable.

Prerequisites

• A pager or alerting tool that can call a webhook with a JSON body when an alert fires.
• A Metaplane API token, and monitor UUIDs available in the pager payload.
• A Slack incoming webhook for briefings and a Discord incoming webhook for the failure path.

Secrets

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

Quick start

1. Add the three secrets to your Kestra namespace.
2. Run the flow manually with a real monitor UUID in the monitor_id input and confirm the Slack briefing arrives.
3. Change the webhook key to a random string, set disabled: false, and point the pager's webhook action at the endpoint with monitorId in the JSON body.

How to extend

• Add a warehouse query task after the fetch to include row counts or last-updated timestamps of the affected table in the briefing.
• Attach runbook links per monitor by mapping monitor IDs to documentation URLs in the flow.
• Escalate automatically when the fetched status is ERROR by adding an If branch that opens a ticket.
• Combine with the Metaplane monitor result reactor blueprint so status changes create pages and this flow enriches them.

Links

• Metaplane plugin documentation
• Metaplane documentation