Dead-man's switch monitoring explained
A dead-man's switch inverts the standard monitoring model. Instead of alerting when a system emits an error signal, it alerts when an expected success signal stops arriving. The monitored system actively sends a ping on each successful run; if the ping doesn't arrive within the expected window, an incident opens — whether the system crashed, was never started, hung indefinitely, or the entire server went offline. Absence is the alert.
Three components: ping, schedule, grace
Every dead-man's switch monitor has exactly three moving parts — and no more.
The ping URL
A unique endpoint the job calls on successful completion:
https://ping.lastping.dev/<uuid>.
Any HTTP method works (GET, POST, HEAD). Append /start to arm
overrun detection, /fail to signal explicit failure, or
/<exit-code> to let the exit code decide.
The schedule
When LastPing expects the ping to arrive. Either a simple interval ("every 24 hours") or a cron expression with an IANA timezone ("0 3 * * *", America/New_York"). The clock starts when the first ping arrives or at the first expected window, whichever comes first.
The grace window
How long past the deadline is still acceptable. A nightly backup expected at 03:00 that sometimes takes until 03:40 should have at least a 60-minute grace window. The incident opens at deadline + grace, not at the deadline itself, to avoid false positives from normal runtime variation.
What each monitoring model catches
Dead-man's switch monitoring and exception monitoring are complementary. You need both for complete coverage.
| Failure type | Exception monitoring | Dead-man's switch |
|---|---|---|
| Uncaught exception / crash | Catches it | Catches it (no ping arrives) |
| Job never ran (crontab lost, machine down) | Blind — nothing to detect | Catches it (no signal in window) |
| Swallowed error (exit 0 after silent failure) | Blind — exit 0 looks healthy | Catches it if ping is gated on real success |
| Hung job (blocked, not yet failed) | Blind — no error has fired yet | Catches it via overrun detection (/start + grace) |
| GitHub Actions schedule silently disabled | Blind — no run, no error | Catches it (no run signal in window) |
| HTTP 500 from an API endpoint | Catches it | Not the right tool for uptime monitoring |
What every dead-man's switch monitor catches
Detection runs on durable deadlines — a LastPing crash or deploy never misses a due monitor.
- The job never ran — crontab lost, scheduler disabled, machine down. No ping in the window → incident.
- The job failed — exit non-zero with
&&: ping skipped, silence → incident. With/fail: explicit failure → immediate incident. - The job hung —
/startarrived, no completion within grace → incident while the job is still running. - Recovery — next successful ping closes the incident automatically. No manual reset required.
- Flap protection — a failure that recovers within the damping window doesn't create alert noise.
Questions people ask
Front-loaded answers — the most important fact first.
-
What is a dead-man's switch in monitoring?
A service that expects a signal from a system on a schedule, and raises an alert when the signal stops arriving. The job sends a ping on successful completion; if the ping doesn't arrive within the expected window, an incident opens — whether the job crashed, never ran, hung, or the server went offline. Also called a heartbeat monitor or cron monitor.
-
What is the difference between a dead-man's switch and exception monitoring?
Exception monitoring (Sentry, Datadog, Rollbar) fires when a broken system emits an error signal. Dead-man's switch monitoring fires when an expected success signal stops arriving. Exception monitoring catches noisy failures; dead-man's switch catches silent ones. You need both for complete coverage of scheduled jobs.
-
What are the three components of a dead-man's switch monitor?
(1) A ping URL — the unique endpoint the job calls on success. (2) A schedule — when the ping is expected (interval or cron expression with timezone). (3) A grace window — how long past the deadline is still acceptable. An incident opens at deadline + grace, not at the deadline itself.
-
Can AI agents use dead-man's switch monitoring?
Yes. The LastPing MCP server at
mcp.lastping.devexposes the ping, start, and fail signals as MCP tools that any AI agent can call directly from its code. This lets agents running on a schedule (nightly Claude runs, automated data pipelines, agent tasks) self-report their heartbeat without any shell access. -
Is LastPing free?
Yes. LastPing is free and fully hosted with no monitor cap and no paid tier. Unlike Healthchecks.io (20-check free plan) or Cronitor (5-monitor free plan), there is no limit on monitored jobs.
Every scheduled job needs a dead-man's switch.
One crontab edit, one webhook, or one API call puts detection in place for any job — and LastPing monitors itself the same way.