How to monitor cron jobs (so they never fail silently)

Why cron jobs fail silently

Standard cron has no concept of monitoring. It runs a command; whether that command succeeds, errors, or never starts, cron says nothing. The common failure modes all share one trait — they are invisible by default:

• The host was down or restarting when the job was due, so it never ran.
• A deploy or config change removed or broke the schedule.
• The script threw an error that was logged to a file nobody reads.
• The job hung on a slow network call and silently timed out.

Two ways to monitor: outbound checks vs heartbeats

There are two complementary approaches, and robust monitoring usually uses both.

Outbound checks: a monitor calls your endpoint on a schedule and records the status code, response body, and timing. This is ideal when the “job” is an HTTP endpoint you want triggered and verified.

Heartbeats (missed-run detection): your existing job pings a unique URL when it finishes successfully. If that ping does not arrive within the expected window, the monitor alerts you. This is the only approach that catches a job that never ran at all.

What good cron monitoring looks like

• Missed-run detection — you are told when an expected run does not happen, not just when one errors.
• A log of every run with status, output, and duration you can scan in seconds.
• Alerting that reaches you where you already are (email, Slack).
• Retries, so one transient blip does not wake you at 3am.
• A short enough check interval to notice problems while they still matter.

Set it up in three steps

With Cronmint, monitoring an existing job is a one-line change — append a heartbeat ping to the end of the command so a successful run checks in:

# runs every hour; pings Cronmint only if backup.sh exits 0
0 * * * * /usr/local/bin/backup.sh && curl -fsS https://cronmint.com/ping/YOUR-TOKEN >/dev/null

Frequently asked questions