Monitoring a Linux cron job

The classic problem with cron: when a job fails or stops running, nobody gets notified. Cron's local mail ends up in/var/mail, which nobody reads. The result: a backup silently broken for 3 weeks, discovered the day you actually need it.

Why crons fail silently

• The server rebooted and crond didn't restart.
• The cron's PATH differs from the interactive shell → command not found.
• The disk is full, or a lock (flock) blocks execution.
• The script crashes but returns exit code 0, so "all good".

The solution: a dead man's switch

Instead of monitoring the server, you ask the cron to report that it ran. If it doesn't report on schedule, the cron itself is the problem. Create a check on Cron-Ping, grab your URL, and add a curl:

# before: you never know if it runs
0 2 * * * /opt/backup.sh

# after: ping only if the script succeeds
0 2 * * * /opt/backup.sh && curl -fsS https://cron-ping.com/p/<token>

Distinguish success from failure

0 2 * * * /opt/backup.sh && curl -fsS https://cron-ping.com/p/<token> || curl -fsS https://cron-ping.com/p/<token>/fail

If backup.sh fails, we call /fail and you get an immediate alert, without waiting for the grace period.

Check that cron is running

systemctl status cron      # Debian/Ubuntu
systemctl status crond     # RHEL/CentOS
grep CRON /var/log/syslog  # see executions