dead man's switch · heartbeat
Dead man's switch monitoring: get a dead man switch email when a cron job stops running
Short answer: a dead man's switch in monitoring is a check that alerts you when something stops happening. Your script pings a unique URL every time it finishes. If that ping does not arrive inside the window you set, AlertPing sends a dead man's switch email, SMS, Slack message or webhook. It is the only way to catch a backup, cron job or data export that fails silently, because a job that never runs also never throws an error.
Last updated July 2026 · SMS, email, Slack and webhook on every plan
alertping ▸ run check
live
▸ type a domain and run a real-feel check
▸ probes from 3 regions · FRA · IAD · SIN
▸ waiting…▌
queued probing▌
If ever goes down, you get:
Alert fired ▸ 2 channels · 6.2 s after first failure
AlertPing app
● DOWN : HTTP timeout confirmed from 3/3 regions (FRA, IAD, SIN). Incident opened.
sms · on-call
AlertPing: DOWN. Confirmed 3/3 regions . First fail: Frankfurt.
the short version
Silence is the failure you never get told about
Every other kind of monitoring watches for a bad answer. A website check waits for a 500. An API check waits for a wrong response body. Both of them need the thing to actually run before they can tell you anything is wrong.
Scheduled work does not fail that way. A cron entry gets commented out during a migration. A server reboots and the scheduler never comes back. A container is rescheduled onto a node without the right credentials. In every one of those cases the job simply does not run, nothing errors, no log line is written, and the first person to notice is whoever needs the backup three weeks later.
A dead man's switch inverts the logic. Instead of waiting for a failure signal, it waits for a success signal and alerts on its absence. You get told about the outage that produces no evidence.
You set the window
A nightly backup gets a 25-hour window. A five-minute sync gets ten minutes. The grace period is yours to pick, so a job that runs a little late does not page anyone.
Your job checks in
One line at the end of the script sends an HTTP request to a unique URL. That request is the proof the work finished. No agent, no daemon, no library to install.
Silence pages you
Window closes with no check-in and the alert goes out by email, SMS, Slack or webhook, naming the job and how long it has been quiet.
how it works
Four steps, about a minute of setup
-
Step 1
Create the switch
Name the job, set how often it should check in, and add a grace period for the runs that finish a few minutes late. You get a unique ping URL back.
-
Step 2
Ping it from your job
Append a curl call to the end of the cron line, or add one request to the last line of your script. Anything that can make an HTTP request can arm the switch.
-
Step 3
We watch the clock
Each check-in resets the timer. The dashboard shows the last ping, the current streak and how much of the window is left before the switch trips.
-
Step 4
Silence sends the alert
No ping before the window closes and the alert fires by email, SMS, Slack or webhook, then again when the job recovers so you know it is back.
crontab ▸ nightly backup with a dead man's switch
armed
# run the backup, then check in only if it exited cleanly
0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://hb.alertping.com/p/YOUR-MONITOR-KEY
last check-in 03:04:11 · expected every 24 h · grace 1 h
next expected in 23 h 55 m▌
The && matters. It means the ping only fires when the backup script exits successfully,
so a job that runs and fails still trips the switch. If you ping unconditionally you are monitoring the
scheduler, not the work.
what it catches
The failures that leave no trace
Every row below is a real way scheduled work stops without anybody being told. None of them produce an error your logging would catch, because the code never gets far enough to log.
| What went wrong | Why nothing alerted you | What a dead man's switch does |
|---|---|---|
| Cron line removed or commented out | The scheduler has nothing to run, so there is no process and no output | Window closes, alert names the job |
| Server rebooted, cron never started | The machine is up and answering pings, so uptime checks stay green | Missing check-in within the hour |
| Script exits before its work | A missing file or bad credential kills it on line one, often silently | Conditional ping never fires |
| Container rescheduled without secrets | The orchestrator reports the pod as healthy and running | No successful run means no ping |
| Backup writes an empty file | Exit code is zero, disk usage barely moves, nobody looks | Ping only after a size check passes |
| Queue worker dies quietly | Jobs pile up in the queue rather than erroring out | Heartbeat from the worker stops |
alertping
Find out tonight, not in three weeks
Arm a dead man's switch on every backup, cron job and scheduled export, and get an email, SMS or Slack alert the first time one goes quiet. Flat pricing from $19 a month, SMS included on every plan.
how it differs
Dead man's switch vs a normal uptime check
These two are complements, not substitutes. One watches things that should answer, the other watches things that should report in. Most teams need both, and both live in the same AlertPing dashboard.
| Dead man's switch | Uptime check | |
|---|---|---|
| Direction | Your job calls us | We call your service |
| Alerts on | An expected signal that never arrived | A bad or missing response |
| Best for | Backups, cron jobs, ETL runs, queue workers, batch exports | Websites, APIs, servers, ports, certificates |
| Works behind a firewall | Yes, only outbound HTTP is needed | No, the target has to be reachable from outside |
| Typical detection time | The grace period you set | 30 to 60 seconds |
If your scheduled work runs on a fixed timetable, the same mechanism is described from the scheduler's side on our cron job monitoring page. For the outward-facing half, see website monitoring and API monitoring.
who arms one
Where teams put a switch first
Database backups
The classic case, and the one that ends careers. A backup that silently stopped running six weeks ago is indistinguishable from a working one until the day you need to restore.
Nightly ETL and reporting
When a warehouse load stops, the dashboards do not go blank. They quietly keep showing yesterday's numbers, and somebody makes a decision on stale data.
Invoice and payout runs
A billing job that skips a cycle turns into a revenue problem and a support queue at the same time, usually discovered by a customer rather than by you.
Certificate renewals
Automated renewal is only automatic while the renewal timer runs. Pair a switch on the renew job with SSL certificate monitoring for the belt and the braces.
Queue and background workers
A worker that dies does not throw errors, it just stops consuming. Have the worker ping every few minutes and you find out in minutes rather than when the queue depth alarms.
Data syncs between systems
Anything moving records between a CRM, a warehouse and a billing system fails quietly by design, because both ends stay healthy while nothing flows between them.
questions
Dead man's switch questions, answered
What does a dead man switch do?
In monitoring, a dead man's switch fires an alert when an expected signal stops arriving. You tell it how often a job should check in, the job sends an HTTP ping each time it finishes, and if a ping is missed inside the grace period the switch trips and notifies you. It catches work that stopped running rather than work that ran and failed.
How does a dead man switch work?
It works on a timer that your job keeps resetting. Each successful run sends a request to a unique URL, which restarts the countdown. As long as check-ins keep arriving, nothing happens. When one is late by more than the grace period you chose, the countdown reaches zero and the alert goes out on every channel you configured.
How do I get an email when a cron job stops running?
Add a dead man's switch and put its ping URL at the end of the cron line, after a double ampersand so it only runs on success. Set the expected interval to match the schedule and add a grace period. Miss a run and you get a dead man's switch email naming the job, the last successful check-in, and how long it has been silent.
Can I use it for jobs behind a firewall?
Yes, and that is one of the main reasons to use one. The job makes an outbound HTTPS request to us, so nothing needs to be reachable from the internet. That makes it the practical way to monitor work on private servers, internal networks and machines behind NAT that an ordinary uptime check can never see.
What is the difference between a dead man's switch and heartbeat monitoring?
They describe the same mechanism from different angles. Heartbeat monitoring names the signal the job sends, and dead man's switch names the alert that fires when the signal stops. Vendors use the terms interchangeably, and a few call the check-in URL a snitch or a ping. The behavior is identical.
What happens when the job comes back?
The next successful check-in clears the alert and sends a recovery notice on the same channels, so nobody has to log in to find out whether the fix worked. The history keeps every check-in, which makes it easy to see whether a job is genuinely fixed or just intermittently late.
keep reading
Related pages
Cron job monitoring
The same check-in mechanism, described from the scheduler side, with setup for crontab, systemd timers and Kubernetes CronJobs.
What is a dead man's switch in monitoring?
The background on where the term comes from and how the pattern is used outside scheduled jobs.
What is heartbeat monitoring?
How heartbeat checks compare with outbound uptime checks, and when each one is the right tool.
Arm a dead man's switch on every job that matters
Backups, cron jobs, ETL runs and queue workers, watched by the clock instead of by hope. Email, SMS, Slack and webhook alerts on every plan, flat from $19 a month.