What is a dead-man's switch in monitoring?

In monitoring, a dead-man's switch (also called a heartbeat monitor or cron monitor) is a service that expects a signal from a system on a schedule, and raises an alert when the signal stops arriving. The name comes from the industrial safety device that must be actively held to prevent a fail-safe from triggering. Applied to scheduled jobs: the job sends a ping on each successful completion; if the ping doesn't arrive within the expected window, an incident opens, whether the job crashed, never ran, hung, or the whole 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.

What is the difference between dead-man's switch monitoring and exception monitoring?

Exception monitoring (Sentry, Rollbar, Datadog alerts) fires when a broken system emits an error signal. Dead-man's switch monitoring fires when an expected success signal stops arriving. This makes them complementary: exception monitoring catches noisy failures (uncaught exceptions, HTTP 5xx), while dead-man's switch monitoring catches silent failures (job never ran, cron daemon stopped, GitHub Actions schedule disabled, machine down). You need both for complete coverage of scheduled jobs.

What are the three components of a dead-man's switch monitor?

Every dead-man's switch monitor has three components: (1) A ping URL: a unique endpoint the job calls on successful completion, e.g. https://ping.lastping.dev/ . (2) A schedule: when the ping is expected, either a simple interval (every 24 hours) or a cron expression with a timezone (0 3 * * *, America/New_York). (3) A grace window: how long past the deadline (the expected ping time) is still acceptable, accounting for variable runtime. An incident opens at deadline + grace, not at the deadline itself.

What does 'heartbeat monitor' mean?

Heartbeat monitor is another name for a dead-man's switch monitor. The metaphor is biological: a healthy heart produces a regular signal; a stopped heart produces silence. In the same way, a healthy scheduled job produces a regular ping; a job that stops (for any reason) produces silence. The monitor hears the silence and raises the alarm.

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.

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 the number of jobs you can monitor.

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.

Your assistant can do this for you

Monitor my cron jobs with LastPing

# 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>

Start monitoring free Platform setup guides

On this page

Three components: ping, schedule, grace
What each monitoring model catches
What every dead-man's switch monitor catches
Questions people ask

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: with &&, a non-zero exit skips the ping and the silence opens an incident. With /fail, the explicit failure opens one immediately.
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?

In monitoring, a dead-man's switch (also called a heartbeat monitor or cron monitor) is a service that expects a signal from a system on a schedule, and raises an alert when the signal stops arriving. The name comes from the industrial safety device that must be actively held to prevent a fail-safe from triggering. Applied to scheduled jobs: the job sends a ping on each successful completion; if the ping doesn't arrive within the expected window, an incident opens, whether the job crashed, never ran, hung, or the whole 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.
What is the difference between dead-man's switch monitoring and exception monitoring?

Exception monitoring (Sentry, Rollbar, Datadog alerts) fires when a broken system emits an error signal. Dead-man's switch monitoring fires when an expected success signal stops arriving. This makes them complementary: exception monitoring catches noisy failures (uncaught exceptions, HTTP 5xx), while dead-man's switch monitoring catches silent failures (job never ran, cron daemon stopped, GitHub Actions schedule disabled, machine down). You need both for complete coverage of scheduled jobs.
What are the three components of a dead-man's switch monitor?

Every dead-man's switch monitor has three components: (1) A ping URL: a unique endpoint the job calls on successful completion, e.g. https://ping.lastping.dev/<uuid>. (2) A schedule: when the ping is expected, either a simple interval (every 24 hours) or a cron expression with a timezone (0 3 * * *, America/New_York). (3) A grace window: how long past the deadline (the expected ping time) is still acceptable, accounting for variable runtime. An incident opens at deadline + grace, not at the deadline itself.
What does 'heartbeat monitor' mean?

Heartbeat monitor is another name for a dead-man's switch monitor. The metaphor is biological: a healthy heart produces a regular signal; a stopped heart produces silence. In the same way, a healthy scheduled job produces a regular ping; a job that stops (for any reason) produces silence. The monitor hears the silence and raises the alarm.
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 the number of jobs you can monitor.

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.

Start monitoring free Platform setup guides