Every system runs work nobody watches: the 3am backup, the nightly export, the certificate renewal, the report that lands in a director's inbox each Monday. These jobs share an awkward property: when they die, they don't make a sound. This explainer covers the monitoring model built for them, why ordinary uptime checks can't help, and which of your scheduled jobs deserve it most.
Key takeaways
- A scheduled job's failure mode is nothing happening, and nothing is invisible on every dashboard built for polling.
- Heartbeat monitoring inverts the model: the job reports in after each successful run, and the missed report is what raises the alarm.
- Two numbers drive it: the expected interval (the schedule) and a grace period (headroom for runtime and retries).
- The ping is one HTTP request chained after the job, sent only on success, so a failed run stays silent and trips the alert.
- Start with backups. A backup that quietly stopped looks identical to a working one until the day you need it.
The plain-English answer
Definition
Cron job / heartbeat monitoring is monitoring for scheduled work. Each job gets a unique URL and pings it after every successful run; the monitor knows the schedule and waits. If the expected check-in doesn't arrive within the interval plus a grace period, it alerts. Because the alarm fires on absence, it's also called a dead man's switch.
The name comes from the same idea on trains and heavy machinery: an operator must keep signalling that they're present, and the machine treats silence as an emergency. Applied to software, the operator is your cron job, the signal is a trivial HTTP request, and the emergency is a scheduled task that stopped running while everything around it looked fine.
The failure nobody hears
Websites and APIs fail loudly: error pages, status codes, spikes on a chart. Scheduled jobs fail by not happening, and not happening produces no error, no log line and no chart movement. It's the one failure your existing monitoring is structurally blind to:
- Websiteup · 99.98%
- APIup · 112 ms
- ServerCPU 34% · disk ok
- Databasehealthy · 41 conns
0 alerts this month
last successful run
23 days ago
- causefull disk · job exits silently
- discoveredduring a restore attempt
The causes are rarely dramatic: a server was rebuilt and the crontab didn't come along, a deploy changed a path, a disk filled, a container image lost its scheduler. What makes them dangerous is the discovery time. A dead web page is found in minutes by the next visitor; a dead backup job is found weeks later, by the restore that needed it. The cost of a silent failure is the gap between when it broke and when you found out, and without monitoring, that gap is unbounded.
Push vs pull: the inversion
The reason your uptime monitoring can't cover this is structural, not a missing feature. Uptime checks pull: a prober requests your URL and judges the response. A cron job has no URL to request; between runs it simply doesn't exist, and there is nothing meaningful to poll. So heartbeat monitoring flips the direction: the job pushes a signal out, and the monitor's job becomes noticing when the signal stops.
external check · pull
no URL to hit
A scheduled job has no inbound endpoint. An HTTP check has nothing to probe, so the job is invisible from the outside.
blind to silent failuresheartbeat · push
pings on success
The job checks in each time it runs. Miss a check-in and we alert: the absence is the signal.
catches the run that never happenedThat one flip has a useful consequence: anything that can send an HTTP request can be monitored. A crontab line, a systemd timer, a Kubernetes CronJob, a scheduled GitHub Actions workflow, a Windows scheduled task, a Celery beat job: if it can run curl or an HTTP call at the end, it can be watched, with no agent to install and no firewall hole to open, since the request travels outbound.
How heartbeat monitoring works
Creating a heartbeat monitor produces a unique ping URL and asks for two numbers: how often the job should run (the expected interval) and how long past that you're willing to wait (the grace period, for runtime, retries and clock drift). Every ping resets the clock; silence past interval plus grace opens the incident:
heartbeat · nightly-backup · every 24h
▲ missed run → alertThe ping itself is deliberately boring: a GET, POST or HEAD to the URL with no body or auth needed, chained after the job with && so it only fires on success. Pings are de-duplicated and rate-limited server-side, so retried runs are safe. When the job recovers and pings again, a recovery notice tells you it's back. The step-by-step cron monitoring guide has copy-paste recipes for crontab, systemd, Kubernetes and CI, plus the tuning advice for interval and grace.
; instead of &&) and a failing job still checks in, keeping the monitor green while the work is broken. Silence must mean failure, so the ping must mean success.What deserves a heartbeat
One heartbeat per job, named so an alert reads instantly. The usual suspects, roughly in order of regret:
- Backups. The canonical case. A backup that silently stopped is indistinguishable from a working one until restore day; if you monitor nothing else scheduled, monitor this.
- Certificate and credential renewals. The renewal timer is a scheduled job like any other; a heartbeat on the job pairs with an SSL check on the result to cover both ends.
- Data pipelines. ETL runs, exports, imports and syncs, where a missed run means a day of stale numbers that somebody makes a decision on.
- Housekeeping with teeth. Database maintenance, log rotation, disk cleanup: dull until the disk fills and takes the application with it.
- Revenue and comms runs. Billing jobs, invoice generation, digest emails, scheduled reports: jobs whose absence a customer notices before you do.
- The schedulers themselves. WordPress's
wp-cronreplaced by a real cron line, scheduled CI workflows that skip silently on busy runners: give the scheduler a heartbeat and you'll know the night it stops (the WordPress guide shows that recipe).
What to look for in a tool
Heartbeat monitoring is simple by design, which makes the small details the differentiators:
- A ping that costs nothing to add. Plain HTTP, any common method, no body, auth or SDK, so one line of
curlfinishes the integration. - Interval and grace as separate controls, so an hourly job with a variable runtime doesn't force a choice between false alarms and slow detection.
- Safe under retries. De-duplication and rate-limiting server-side, so a job that retries or double-fires never corrupts the signal.
- Recovery notices, because a job that caught up on its own at 4am is information, not a mystery to untangle at 9.
- Alerts where the team lives: email, Slack, Teams, Telegram, Discord, SMS or a webhook, with each heartbeat routed like any other monitor.
- A free tier that covers real jobs. 247Monitor includes heartbeats in the 25 free monitors, enough for the backup, the renewals and the pipeline without a card.
Frequently asked questions
What is cron job monitoring?
Cron job monitoring watches scheduled tasks (cron jobs, systemd timers, Kubernetes CronJobs, scheduled CI workflows) by giving each job a unique URL to ping after every successful run. The monitor knows how often the job should run; if a ping fails to arrive within the expected interval plus a grace period, it opens an incident and alerts you. The missing run is the signal.
How does heartbeat monitoring work?
You set two numbers: the interval the job is expected to run on, and a grace period for runtime and retries. The job sends a simple HTTP request to its ping URL when it finishes successfully, and every ping resets the clock. Let the clock run past interval plus grace with no ping, and the monitor alerts. When pings resume, a recovery notice follows.
Why can't normal uptime monitoring watch cron jobs?
Uptime monitoring is a pull model: a prober requests your URL and checks the response. A scheduled job has no URL, no port and nothing to request; between runs it doesn't exist. The only workable model is push: the job reports in, and the absence of that report is what gets detected.
Which jobs should have heartbeat monitoring?
Anything scheduled whose absence hurts: backups first, then database maintenance, ETL and data syncs, certificate renewal jobs, queue and email digests, billing and report runs, and scheduled CI workflows. One heartbeat per job, so an alert tells you exactly which one went quiet.
Is cron job monitoring free?
Yes. 247Monitor's free plan includes 25 monitors, heartbeats among them, with six non-SMS alert integrations and no card required. That covers backups, renewals and scheduled reports for most small teams.
Scheduled work fails in silence, so the monitoring has to listen for silence. Give each job a heartbeat, ping only on success, and the jobs nobody watches become the jobs that report in every day. 247Monitor includes Cron / Heartbeat checks on every plan, and the hands-on guide gets your first one running in a few minutes.