Page Squadcast with Kestra Execution Context

A page that says "the pipeline failed" starts a search; a page that carries the execution id, flow, and namespace starts a fix. This blueprint uses io.kestra.plugin.squadcast.SquadcastExecution, the plugin's execution-aware task, at the end of the errors block of a critical flow. Where the raw SquadcastIncomingWebhook sends whatever payload you compose, SquadcastExecution is built to ship Kestra execution context, its executionId property defaults to {{ execution.id }} and switches to {{ trigger.executionId }} for flows launched by Flow triggers, and customFields plus customMessage enrich the incident with structured triage data.

How it works

1. extract_customers (io.kestra.plugin.core.http.Request) performs the monitored work against the source_url input, and record_success logs quietly when it succeeds.
2. On failure, the errors block first posts a short Slack heads-up (notify_channel), so the team channel knows a page is going out and nobody double-escalates.
3. page_with_context (io.kestra.plugin.squadcast.SquadcastExecution) then opens the incident with message, executionId set explicitly to {{ execution.id }}, customFields carrying flow and namespace, and a customMessage telling on-call where to look first.
4. Compared to the raw webhook task, the dedicated task documents executionId as a first-class property with a sensible default, so the incident is always correlated to the exact execution that failed rather than to whatever string a hand-rolled payload happened to include.

What you get

• Incidents that identify the failing execution by id, ready to paste into the Kestra UI search.
• Structured customFields on the notification, flow and namespace arrive as data, not prose.
• A customMessage slot for runbook pointers that ride along with every page.
• A channel heads-up preceding the page, keeping chat informed without making chat the pager.

Who it's for

• Teams running many flows who need pages that identify the failing execution without a search.
• On-call engineers tired of alerts that require asking "which run was this" in a thread.
• Platform owners standardizing one failure-paging pattern across namespaces.

Why orchestrate this with Kestra

Execution context is something only the orchestrator has. Because the paging task runs inside the failing execution, Kestra fills in the execution id, flow, and namespace at render time with zero plumbing, and the errors block guarantees the page fires for any task failure in the flow, present or added later.

Prerequisites

• A Squadcast Incoming Webhook (API) integration on the target service.
• A Slack incoming webhook for the channel heads-up.

Secrets

• SQUADCAST_WEBHOOK_URL: the full Squadcast incoming webhook endpoint, including its token.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add both secrets to your namespace.
2. Execute with the default input and confirm the quiet success log.
3. Execute with source_url set to an unreachable URL and confirm the Slack heads-up plus a Squadcast incident carrying the execution id, flow, and namespace.
4. Replace extract_customers with your real critical tasks.

How to extend

• Add more customFields, such as environment, data domain, or owning team, so Squadcast routing rules can act on them.
• Use this errors block as the standard failure handler across your namespace's critical flows.
• Combine with the flow failure pager blueprint when you want priority and event id semantics on the same incident.
• Set executionId to {{ trigger.executionId }} and attach this pattern to a Flow trigger that watches other flows for failure, one pager flow for the whole namespace.

Links

• Squadcast plugin documentation
• Squadcast incident webhook documentation