Cron monitoring that catches the job that never ran
A cron job that errors is easy to spot. The dangerous one is the job that quietly stopped running. Here is how heartbeat and deadline monitoring catch both.
Your nightly backup has been failing for three weeks and nothing alerted you. Nothing errored, because after a deploy the job simply stopped being scheduled. The script that would have emailed you on failure never ran either.
This is the blind spot of most cron monitoring. You can only alert on a job that runs.
Heartbeats flip the problem around
Instead of waiting for a job to report a failure, heartbeat monitoring waits for it to report success, and alerts you when that success does not arrive in time.
You add a ping at the end of your job:
0 2 * * * /usr/local/bin/backup.sh && curl -fsS https://ping.cronaut.dev/your-check-idIf you want more detail, signal start, success and failure separately:
curl -fsS https://ping.cronaut.dev/your-check-id/start
backup.sh && curl -fsS https://ping.cronaut.dev/your-check-id # success
# or on failure:
curl -fsS https://ping.cronaut.dev/your-check-id/failDeadlines and grace periods
Cronaut reads your cron expression, so it knows when the next ping is due. Miss that deadline, plus a grace period you set for a slow run, and the check moves to DOWN. That change opens an incident and fires your alerts, the same way a failed HTTP probe does.
A missed ping is handled carefully on purpose. One late run should not page you, but a job that has gone quiet should. Grace periods and flap detection are where you draw that line.
Why it sits next to your uptime checks
Cron checks run on the same engine as your HTTP and SSL checks, so a silent backup failure shows up on the same dashboard and the same status page as a downed API. There is one place to look when something feels wrong.