Which monitoring approach catches a nightly cron job that silently stopped running?

Why ordinary uptime checks cannot see a missing job

An uptime check is a question you ask: is this endpoint responding? A scheduled job is the opposite. It is something that should happen on its own, at a time, without anyone asking. When it fails to run, there is no endpoint returning an error. There is simply nothing. The server that hosts the job may be perfectly healthy, its web app returning 200 all night, while the backup, the nightly report, the subscription renewals, or the data sync never started. Nothing in a request-based monitor is designed to notice absence. Related: Uptime vs Response Time: What to Monitor and Why Both Matter

The failure causes are mundane and rarely produce alerts on their own: a container rebuilt without its cron entry, a system clock or time zone change, a job that hangs on a lock and never exits, a credential that expired and caused a silent early return, a disk that filled up so the log line was never written. Teams usually discover these when a customer asks why their invoice did not arrive, or during a restore when the most recent backup turns out to be weeks old.

Keep reading: How to Choose an Uptime Check Interval That Actually Catches Outages, Status Page Best Practices That Reduce Support Tickets, Uptime vs Response Time: What to Monitor and Why Both Matter. See how PingCrumb helps you uptime monitoring and hosted status pages.

How heartbeat monitoring turns silence into a signal

The model is simple. Each scheduled job is given a unique URL. At the end of a successful run, the job sends a request to that URL. The monitoring service expects that request on a schedule, for instance every 24 hours with a grace period of 30 minutes. If the expected request does not arrive in time, the service alerts. The job does not need to know anything about the monitor beyond a single HTTP call, which can be a one-line addition to a shell script, a request appended to a cron line, or a call in the job's success path. Related: How to Set Up Alerting That Avoids False Alarms

The important detail is where the ping goes in the job. Send it only after the work has verifiably completed, not at the start. A backup script should ping after it has confirmed the archive exists and has a plausible size, not after the command was merely invoked. Some setups send a start ping and a finish ping, which also gives you run duration and catches jobs that hang. Failure paths can send a distinct failure signal so that a job that ran and crashed is reported differently from one that never ran at all.

Setting schedules and grace periods that do not cry wolf

Grace periods are the tuning knob. A nightly job scheduled at 02:00 that usually takes ten minutes might get a grace of one hour, so a slow night or a delayed start does not page anyone. A job that runs every five minutes might get a grace of ten. The rule of thumb is to set the grace to a bit longer than the worst legitimate run you have seen, and then tighten it once you have a few weeks of timing data. Too tight, and you wake up for jobs that were merely slow. Too loose, and a job that is truly dead goes unnoticed for a day.

Decide which jobs deserve a page and which deserve a morning message. A missed backup or a missed billing run is worth a page. A missed cache warm or a missed analytics rollup can wait. Also handle jobs that legitimately run at irregular times, such as weekday-only schedules, by expressing the schedule in cron syntax on the monitor side rather than as a fixed interval, so a quiet weekend does not trigger a false alert on Saturday morning.

Extending the same idea beyond cron

Once you have heartbeat checks for cron, the same pattern covers anything that should happen regularly. A queue worker can ping every few minutes while it is alive. A data pipeline can ping at each stage boundary. A device or an on-premises agent behind a customer's firewall, which you can never reach with an inbound check, can ping outward. An ETL job that runs on a third-party platform where you cannot install monitoring can still call a URL when it finishes. Anywhere you cannot ask the question, let the process report the answer. Related: SSL Certificate Expiry: How to Never Get Caught Offline

Keep an inventory. The failure mode of heartbeat monitoring is not false alarms but forgotten jobs that never got a check in the first place. When a new scheduled task is added, adding its heartbeat should be part of the same change. A quarterly review of the crontab against the list of monitored heartbeats takes minutes and catches the jobs that slipped through. We added heartbeat checks to PingCrumb after watching this happen to our own nightly export, which is exactly the kind of quiet failure this approach prevents. Related: How to Choose an Uptime Check Interval That Actually Catches Outages