What Is a Heartbeat (Cron) Monitor and When to Use One
VigilDog Team · September 1, 2026 · 6 min read
Most monitoring answers the question 'is this thing up?' A heartbeat monitor answers a harder and often more important one: 'did this thing run when it was supposed to?' The difference matters because the failures that hurt most are the silent ones, the nightly backup that quietly stopped, the cron job that's been dead for a week, the queue worker nobody noticed had crashed. This guide explains what a heartbeat monitor is, how it works, and when reaching for one is the right call.
What a heartbeat monitor actually is
A heartbeat monitor, also called a dead man's switch or cron monitor, inverts the usual model. Instead of the monitoring system reaching out to check on your service, your service reaches out to the monitor on a schedule. Each successful run sends a small 'I'm alive' ping. The monitor's only job is to notice when an expected ping fails to arrive within its window, and to alert you when it doesn't.
That inversion is the whole point. An uptime check confirms a server answers a request right now. A heartbeat confirms that a specific piece of scheduled work actually executed. The absence of a signal is the alarm, which is exactly what you want for anything that's supposed to happen on a timer but has no user staring at it when it doesn't.
Why uptime checks miss silent failures
Consider a nightly database backup. The server it runs on is up all day, responds to every ping, and passes every uptime check, while the backup script itself has been failing silently for two weeks because a disk filled up or a credential expired. Your uptime dashboard is a wall of green. You find out the backup is broken at the worst possible moment: when you need to restore.
Uptime monitoring watches the host. It has no idea whether the work you care about ran. Batch jobs, backups, data pipelines, and scheduled tasks fail independently of the machine's health, and their failures produce no error a user will report, because there is no user. That blind spot is precisely the one a heartbeat fills. If this distinction is new to you, it's the same reasoning behind SSL monitoring versus uptime monitoring: watching the thing that actually matters, not just whether the door opens.
When to use one
Heartbeat monitors shine anywhere a task runs on a schedule with no human in the loop. The tell is simple: if the job stopped running tonight, how long until someone noticed? If the honest answer is 'days' or 'when something downstream broke,' it needs a heartbeat.
They're less useful for continuously running, user-facing services, those are better served by direct uptime and health checks, because you want to know the instant a request fails, not merely that a periodic signal went missing.
- Cron jobs and scheduled tasks of every kind
- Nightly or hourly backups and database dumps
- ETL and data-pipeline runs
- Queue and background workers that should process on an interval
- Certificate-renewal and cleanup scripts
- Any regularly scheduled report or export
How it works: expected interval and grace period
You configure a heartbeat with two numbers: how often you expect a ping (the period) and how much lateness is tolerable before it alarms (the grace period). A backup that runs at 2 a.m. and usually finishes in ten minutes might be set to expect a ping every 24 hours with a 30-minute grace. Ping on time and the monitor stays quiet; miss the window past the grace and it alerts.
The grace period is what keeps a heartbeat from crying wolf. Real jobs vary, a backup takes longer as data grows, a pipeline waits on an upstream feed. Set the grace too tight and you'll get false alarms; too loose and you'll learn about failures hours late. Tuning that window to your job's real-world variance is the single most important configuration decision.
Setting one up well
The mechanics are easy, usually a single HTTP request to a unique URL, but a few habits separate a heartbeat that helps from one that lies to you. Put the ping at the very end of your script, after the work succeeds, so a job that starts but fails partway through never reports success. If you can, signal start and finish separately, so a job that hangs forever is caught rather than looking like it simply hasn't pinged yet.
Then route the alert somewhere a human will actually see it out of hours, and resist the urge to monitor everything at once. A flood of low-value heartbeat alerts trains people to ignore them, which is worse than no monitoring at all. Start with the jobs whose silent failure would genuinely hurt, get their grace periods honest, and expand from there.
Heartbeats alongside outside-in monitoring
A heartbeat covers the work you run on a schedule. It's the natural complement to the checks that watch your public surface from the outside, domain expiry, SSL and TLS validity, DNS drift, and email authentication, because together they close both blind spots: the scheduled job that silently died, and the certificate or record that silently changed. Neither replaces the other.
That combined view is what VigilDog is built around: outside-in monitoring of the things that break quietly and cost you when they do, with alerts that reach the right person before a silent failure becomes a visible outage. See pricing if you want to fold scheduled-job and infrastructure monitoring into one place.