Page Squadcast on Batch SLA Breach

A batch that finishes late can be worse than a batch that fails, because nothing errors and nobody looks. This blueprint makes the SLA itself the alarm condition. The flow runs its batch work, then computes elapsed time from {{ execution.startDate }} and compares it against an sla_seconds input inside an If task. A breach opens a Squadcast incident through io.kestra.plugin.squadcast.SquadcastIncomingWebhook, tagged with the flow and the SLA that was blown; a run inside the window writes one log line and raises nothing.

How it works

1. start_batch logs the SLA for the run, and batch_work (io.kestra.plugin.core.flow.Sleep) stands in for the real workload with a duration taken from the batch_duration input.
2. check_sla (io.kestra.plugin.core.flow.If) evaluates (now() | timestamp) - (execution.startDate | timestamp) > inputs.sla_seconds, plain epoch arithmetic on the execution's own start time, no extra state needed.
3. On breach, page_sla_breach posts a JSON payload with status: trigger, the execution id as event_id, and tags carrying the flow and the SLA value, so the incident says exactly which contract was broken.
4. Within SLA, log_within_sla records the healthy run, turning the execution history into an SLA compliance trail.
5. The errors block reports to Slack when the pager flow itself fails, because an unpaged breach is invisible.
6. A disabled-by-default nightly Schedule runs the batch at 02:00.

What you get

• SLA enforcement measured from the execution's real start time, not from a wall clock someone has to watch.
• Incidents that name the breached contract, flow and SLA arrive as Squadcast tags.
• A quiet success path, so paging stays meaningful.
• A fallback channel when paging itself breaks.

Who it's for

• Data teams with delivery commitments to downstream consumers, dashboards, ML features, or partner exports.
• On-call engineers who need late batches escalated with the same weight as failed ones.
• Anyone whose current SLA monitoring is a human noticing the dashboard looks old.

Why orchestrate this with Kestra

The orchestrator already knows when the execution started and what it contains, so SLA measurement costs one Pebble expression instead of an external monitoring stack. Kestra provides the schedule, the branching, the pager integration, and a durable per-run record of SLA compliance in one flow.

Prerequisites

• A Squadcast Incoming Webhook (API) integration on the target service.
• A Slack incoming webhook for the pager-failure fallback.

Secrets

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

Quick start

1. Add both secrets to your namespace.
2. Execute with defaults and confirm the within-SLA log line.
3. Execute with sla_seconds set to 3 and batch_duration at PT5S, and confirm a Squadcast incident opens tagged sla: 3s.
4. Replace batch_work with your real batch tasks and enable the nightly trigger.

How to extend

• Set sla_seconds per environment with namespace variables so production pages harder than staging.
• Add a mid-flow checkpoint that pages early when extraction alone has consumed most of the SLA budget.
• Resolve the incident automatically when the next run lands inside the window, as shown in the incident resolve sync blueprint.
• Record elapsed seconds as a metric for trend dashboards before the breach ever happens.

Links

• Squadcast plugin documentation
• Squadcast incident webhook documentation