Cron Job Monitoring: Catching the Failures Nobody Sees

The problem with cron jobs: silence is the default

A web server that crashes is loud — users notice, error rates spike, someone gets paged. A cron job that stops running is silent by default: cron doesn't email on failure unless you've configured it to, and even then, a broken mail relay means that email never arrives either. The job that used to back up your database every night can simply stop running, and nothing in your normal monitoring will notice, because nothing "went down" — a scheduled event just stopped happening.

Heartbeat monitoring: the simplest fix

The standard pattern is a "heartbeat" or "dead man's switch" check: your cron job pings a monitoring endpoint when it completes successfully. The monitoring service expects that ping on a schedule; if it doesn't arrive within an expected window (plus a grace period), it alerts you.

A typical setup looks like this at the end of an existing script:

```

your-backup-script.sh && curl -fsS https://hc.example.com/ping/your-unique-id

```

The `&&` matters — the ping only fires if the preceding command succeeded, so a failed script (non-zero exit code) correctly does not send a heartbeat, and you get alerted.

What to monitor this way

• Database and file backups.

• Data sync or ETL jobs.

• Cleanup/maintenance scripts (log rotation, temp file cleanup).

• Certificate renewal jobs (see also: [SSL certificate monitoring](/features/ssl-certificate-monitoring), which checks the actual served certificate independently as a second layer of defense).

• Any scheduled task where "it just didn't run" would only be discovered when its absence causes a separate problem.

Grace periods and runtime alerts

Real-world jobs don't always run at the exact same second every time — server load, network conditions, or job dependencies can shift timing by a few minutes. A workable setup includes a grace period (e.g., "expected daily around 2am, alert if no ping by 3am") rather than an exact-second match. It's also worth alerting on runtime, not just completion: a backup job that normally finishes in 3 minutes but is still running after 45 is worth knowing about even before it technically fails.

CloudStats' [cron job monitoring](/features/cron-job-monitoring) covers heartbeat checks, configurable grace periods, and runtime alerts with a single line added to your existing scripts.