Guide

What Is Dead Man's Switch Monitoring?

A dead man's switch monitor watches for the absence of a signal, not the presence of a failure. Here's what that means for cron jobs, backups, and other scheduled tasks — and how to set one up.

Last updated July 2026.

Short answer

Dead man's switch monitoring (also called heartbeat monitoring) flips the usual monitoring model: instead of a service actively checking whether your job is working, your job checks in with the monitor on a schedule. If the check-in ("ping") doesn't arrive within an expected window, the monitor assumes something went wrong and alerts you. It's built for jobs that run on a schedule in the background — cron jobs, backups, ETL syncs, scrapers, and workers — where the failure mode is the job silently not running at all, which nothing is around to notice unless something is watching for the missing ping.

Where the term comes from

"Dead man's switch" originally describes a safety mechanism that requires continuous, active input from an operator — a train driver holding down a pedal, for example — and triggers a fail-safe the moment that input stops. Applied to software, the "continuous input" is a periodic ping from a running job, and the "fail-safe" is an alert. The switch doesn't need to know why the input stopped; it only needs to know that it did.

How it works for scheduled jobs

You point a cron job, backup, ETL sync, scraper, or background worker at a unique ping URL. Each time the job runs successfully, it pings that URL — typically a single HTTP request at the end of the job. The monitor expects that ping on the job's schedule, plus a grace window to absorb normal timing jitter. If a ping doesn't arrive in time, the monitor treats the job as down and sends an alert.

Dead man's switch monitoring vs. uptime monitoring

Uptime monitoring actively probes a URL or endpoint from the outside and alerts if it doesn't respond — useful for things that are supposed to be reachable all the time, like a website or an API. Heartbeat (dead man's switch) monitoring is the inverse: it doesn't probe anything. Your job reaches out to the monitor, not the other way around. That makes it a better fit for anything that runs on a schedule rather than staying always-on — a nightly backup, an hourly sync, a weekly report — where there's no "up" endpoint to probe between runs.

What to point at a heartbeat monitor

Anything that's supposed to run on a schedule and doesn't have anyone watching it in real time:

How PingDeck implements it

PingDeck is a heartbeat monitor built specifically for this model: you get a unique ping URL per monitor, your job pings it when it runs, and if a ping doesn't arrive on schedule (plus its grace window), PingDeck alerts you by email, Slack, Discord, webhook, or Telegram. It's scoped to heartbeat monitoring only — it doesn't do outbound uptime probing, and it's built for solo devs and small teams rather than enterprise on-call setups.

Free vs. Pro

Feature Free Pro — $12/mo
Monitors 20 100
Check interval All intervals, including 1-minute All intervals, including 1-minute
Alert channels Email, Slack, Webhook, Discord, Telegram Email, Slack, Webhook, Discord, Telegram
Ping log depth 100 pings per monitor 1000 pings per monitor
History window 30 days 30 days
Support Priority email, answered within 1 business day
Credit card required No

Every alert channel is free on every tier — Pro is about headroom (more monitors, deeper ping history), not unlocking channels or faster check intervals.

Set up your first heartbeat monitor free

20 monitors, every alert channel, no card required.

Start monitoring free →

Sources: PingDeck's model and plan details in this guide are drawn directly from this project's CLAUDE.md and PRICING.md. The historical framing of "dead man's switch" is general background, not a claim about any specific product.