CONCEPT · MONITORING MODEL · DEFINITIONAL

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.

# The entire integration — append this to any cron job 0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 -o /dev/null \ https://ping.lastping.dev/<your-monitor-id>
Create a monitor — free Platform setup guides

Three components: ping, schedule, grace

Every dead-man's switch monitor has exactly three moving parts — and no more.

Component 1

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.

Component 2

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.

Component 3

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)
Long job that stops making progress mid-way Blind — no error, and the process is alive Catches it via stall detection (/step + step_timeout_s), naming the stage it stopped in
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 — /start arrived, no completion within grace → incident while the job is still running.
  • The job stopped making progress — the run reported /step pings and then went quiet for longer than step_timeout_s → incident naming the stage it wedged in, without waiting out the whole run budget. Opt-in; a monitor that sets no step_timeout_s is unaffected.
  • 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. A long job can optionally report a progress step per stage and set step_timeout_s, which also catches a run that is still alive but has stopped making progress, and names the stage it wedged in. 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.dev lets an agent create its own monitor and receive its check-in code in one conversation: create_monitor followed by get_ping_instructions, which returns ready-to-run start, success, fail and step requests for that monitor. The check-ins themselves are plain HTTP — no SDK, no library, and nothing to install — so agents running on a schedule (nightly Claude runs, data pipelines, agent tasks) can report their own heartbeat from any language.

  • Is LastPing free?

    Yes. LastPing is free for individuals with no monitor cap. Unlike Healthchecks.io (20-check free plan) or Cronitor (5-monitor free plan), there is no limit on monitored jobs.

FREE FOR INDIVIDUALS · FULLY HOSTED

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.

Create a monitor — free Platform setup guides