Page Squadcast When a Heartbeat Goes Silent

Systems that die loudly page themselves; systems that just stop need a witness. This blueprint is that witness. On a schedule, it probes an upstream heartbeat endpoint with io.kestra.plugin.core.http.Request and allowFailed: true, branches on the status code, and opens a Squadcast incident through io.kestra.plugin.squadcast.SquadcastIncomingWebhook when the answer is anything but 200. The incident's priority comes from an input, and its event id is stable per monitored endpoint, so an outage spanning several checks feeds one incident instead of paging on-call once an hour.

How it works

1. probe_heartbeat (io.kestra.plugin.core.http.Request) calls the heartbeat_url input with allowFailed: true, so 4xx and 5xx responses keep the task green and expose the code as an output.
2. route_probe (io.kestra.plugin.core.flow.If) branches on outputs.probe_heartbeat.code != 200.
3. On silence, page_silence opens the incident with priority from the page_priority input, status: trigger, tags carrying the flow and the observed HTTP code, and an eventId of heartbeat-{{ flow.namespace }}-{{ flow.id }}. The stable id lets Squadcast correlate repeated triggers and lets a resolve call close the incident when the heartbeat returns.
4. On a 200, log_alive writes one line, turning the execution history into an uptime trail.
5. A hard probe failure, DNS, connection refused, or a broken pager webhook, lands in the errors block, which tells Discord the upstream is currently unmonitored, because a dead monitor feels exactly like a healthy system.
6. A disabled-by-default hourly Schedule runs the check at the top of each hour.

What you get

• Detection of the failure mode that never raises its own alert, a system that silently stopped.
• One incident per outage, not one page per check interval, thanks to the stable event id.
• Priority as an input, so the same flow can page P1 for payments and P3 for a staging feed.
• An explicit unmonitored signal when the monitor itself breaks.

Who it's for

• Teams depending on upstream systems owned by other teams or vendors.
• On-call engineers who have learned that no news is not good news.
• Anyone replacing a cron-plus-curl heartbeat script that nobody maintains.

Why orchestrate this with Kestra

A heartbeat monitor needs a scheduler, an HTTP client, branching, a pager, and its own failure handling, and it must never be the thing that silently stops. Kestra supplies each piece declaratively and keeps every probe in the execution history, so the monitor's own liveness is auditable too.

Prerequisites

• A heartbeat or health endpoint on the upstream system reachable from Kestra workers.
• A Squadcast Incoming Webhook (API) integration on the target service.
• A Discord incoming webhook for the monitor-down fallback.

Secrets

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

Quick start

1. Add both secrets to your namespace.
2. Execute with the default input and confirm the alive log line.
3. Point heartbeat_url at a URL returning 404 and confirm a Squadcast incident opens with your chosen priority.
4. Set heartbeat_url to your real health endpoint and enable the hourly_check trigger.

How to extend

• Auto-resolve the incident by sending status: resolve with the same event id from the healthy branch, closing the loop when the heartbeat returns.
• Probe several upstreams in one flow with ForEach and give each a distinct event id.
• Tighten the cadence to every five minutes for tier-1 dependencies by editing the cron expression.
• Check response body content, not just the status code, when the endpoint can answer 200 while degraded.

Links

• Squadcast plugin documentation
• Squadcast incident webhook documentation