Heartbeat Monitoring for Cron Jobs and Scheduled Tasks
A cron expression tells you when a job should run. A heartbeat tells you whether it actually ran. This guide covers grace periods, late versus missed jobs, and URL security without installing an agent.
A cron expression tells you when a job should run. A heartbeat tells you whether it actually ran. Heartbeat monitoring expects a periodic ping from the job. When the ping stops, you investigate. No agent required on the host beyond the HTTP request your job already knows how to make.
How a heartbeat works
- You create a heartbeat monitor with an expected period and a grace period.
- Your job requests the heartbeat URL after a successful run.
- If a ping arrives late but within grace, you may record lateness without paging.
- If no ping arrives before grace ends, the monitor alerts on a missed run.
Use the cron expression explainer to confirm the schedule you think you deployed.
Late vs Missed vs Silent Success
| Outcome | Meaning | Typical response |
|---|---|---|
| On-time ping | Job finished inside the expected window | None |
| Late ping | Job finished after the period but inside grace | Investigate slow runs |
| Missed ping | No successful ping before grace ended | Alert and check the job |
| Silent success | Job ran but never called the heartbeat | Fix instrumentation; treat as miss until fixed |
Silent success is the sneaky failure mode. The business outcome happened, but monitoring stayed blind. Put the ping in the success path only after the work commits, and alert when pings disappear.
Choosing a grace period
Grace covers clock skew, queue delay, and occasional slow runs. Too short and you page for normal variance. Too long and customers feel the failure before you do.
- For hourly jobs, start with 15 to 30 minutes of grace.
- For daily jobs, start with one to three hours.
- For tight every-minute jobs, grace may be a few minutes; expect more noise.
Minimal job snippet
# After a successful backup
curl -fsS -X POST "$HEARTBEAT_URL"Ping only after success. A ping before the work finishes hides failures. Product setup: Heartbeat monitoring.
Heartbeat URL security
- Treat the URL as a secret. Anyone with it can fake a healthy ping.
- Do not commit it to public repos.
- Rotate if it leaks.
- Prefer environment variables or a secret store.
Related terms: heartbeat URL, grace period.
Serverless and CI schedules
Cloud schedulers and CI cron wrappers fail in boring ways: permissions expire, a workflow file moves, a secret rotates. Heartbeats still help because the success path is under your control. Ping from the job after the work commits, not from the scheduler that merely attempted a start.
If a platform can start a run but your code never finishes, the missing heartbeat is the signal. That is the failure mode backups die from.
What heartbeats do not catch
A heartbeat does not prove the job did the right work. It proves the success path ran far enough to ping. Pair critical jobs with downstream checks when correctness matters as much as completion.
Start with one heartbeat on the job whose silence would hurt most. Expand after that ping is boringly reliable.
Plain-text version · Cron and Scheduled Jobs
Was this useful?