Dead Man's Switch for Scheduled Tasks — What It Is and How to Set One Up

A dead man's switch is a simple concept: if someone (or something) stops checking in, sound the alarm.

In trains, it's a pedal the conductor must keep pressed. In software, it's a URL your scheduled task must ping on every run. If the ping stops coming, something broke — and you need to know about it.

Why you need one

The hardest failures to catch are the ones that don't produce errors. A cron job that silently stops running doesn't send an alert. A backup script that can't write to a full disk exits quietly. A queue worker that gets killed by the OOM killer doesn't log a goodbye.

Traditional monitoring answers "is this thing up?" A dead man's switch answers a different question: "did this thing run?"

If you have any automated process that runs on a schedule — backups, data syncs, report generators, cleanup scripts — you need a dead man's switch for each one.

How it works

The mechanism is almost trivially simple:

1. You define how often you expect a task to run (every 5 minutes, every hour, once a day)
2. A monitoring service gives you a unique URL
3. Your task pings that URL every time it completes successfully
4. If the monitoring service doesn't receive a ping within the expected window (plus an optional grace period), it alerts you

That's the entire system. The value isn't in the complexity — it's in the coverage. You now have positive confirmation that every critical scheduled process actually ran.

Setting one up with PoppaPing

Create a heartbeat monitor:

1. Log in and click Add Monitor
2. Select the Heartbeat type
3. Set the expected interval (how often your task runs)
4. Set a grace period (how much slack to allow for slow runs)
5. Copy the generated heartbeat URL

Then add one line to the end of your task:

# At the end of your cron job / scheduled task
curl -fsS https://poppaping.com/heartbeat/YOUR_TOKEN

The -f flag makes curl return a non-zero exit code on HTTP errors. The -sS flags suppress progress output but still show errors. This is the standard pattern — it won't pollute your logs but will surface problems.

Best practices

Ping after success, not before. Put the heartbeat call at the end of your script, after the actual work completes. If you put it at the beginning, a script that starts but crashes halfway through will still send a heartbeat — defeating the purpose.

One monitor per task. Don't combine multiple cron jobs into one heartbeat. If your backup and your log rotation share a heartbeat, you won't know which one failed.

Match the interval to your schedule. If the cron job runs every hour, set the heartbeat interval to 1 hour. If it runs daily, set it to 24 hours.

Use grace periods generously. A task that normally takes 2 minutes but occasionally takes 10 shouldn't trigger false alarms. Set the grace period to accommodate your worst-case runtime with some margin.

Test the failure case. Temporarily disable the cron job and verify you actually receive the alert. A monitoring system you've never seen fire isn't one you can trust.

Common use cases

Task	Interval	Grace	Why
Database backup	24h	1h	Losing backups is catastrophic and often unnoticed
SSL cert renewal	12h	2h	Auto-renew fails more often than you think
Log rotation	24h	30m	Full disks cascade into outages
Data pipeline / ETL	1h	15m	Stale data produces wrong business decisions
Temp file cleanup	6h	30m	Disk space doesn't manage itself
Health check reporter	5m	2m	If the reporter dies, who monitors the monitor?

The cost of not having one

Every operations team has a story: "We found out the backups hadn't run for a month when we tried to restore from one." The recovery from that scenario is always painful, always expensive, and always preventable.

A dead man's switch for your critical scheduled tasks costs minutes to set up. Not having one costs hours (or days) in incident response when you discover the gap at the worst possible time.

PoppaPing's heartbeat monitoring is available on paid plans starting at $5/month. One monitor per critical task, 60 seconds each to set up, and you'll never be surprised by a silently failing cron job again.