Some of the most expensive failures do not take a website offline. A nightly backup can stop running. A queue worker can stop sending receipts. A data import can silently miss a day. The homepage stays green while the business process fails.
Heartbeat monitoring is designed for this problem. Instead of asking a monitoring service to visit your job, the job sends a signal when it completes. If the expected signal does not arrive within its schedule and grace period, the team receives an alert.
Choose jobs worth monitoring
Start with tasks that have a clear expected schedule and a meaningful consequence if they fail: database backups, billing runs, order exports, email digests, feed imports, report generation, and cleanup tasks. List the owner and normal completion window for each one.
Do not create a heartbeat for every tiny internal task. Monitor the jobs whose failure someone must investigate.
Send the signal after success
The most important implementation detail is when the job reports completion. A signal sent as soon as the job starts proves only that scheduling worked. It does not prove the job finished.
Place the success signal after the critical work is complete. If the job has several stages, check that each required stage succeeded before sending it. Avoid printing a private heartbeat URL in logs or sharing it in public examples; anyone with that URL might be able to send a false success signal.
For long-running jobs, decide whether you need an additional start or failure event for your own logs. The heartbeat should still represent the outcome you care about.
Set a realistic grace period
Suppose a job is scheduled for 02:00 and usually finishes between 02:05 and 02:12. Alerting at 02:01 creates noise. Alerting at 04:00 hides a real failure. Start with a grace period based on observed runtime and the business deadline, then adjust it if the job regularly finishes later than expected.
Check time zones and daylight-saving behavior for scheduled jobs. A clear schedule in UTC, plus a documented local reporting time, prevents avoidable confusion.
Decide what happens after an alert
Every missed heartbeat needs a first-response checklist:
- Confirm the scheduler ran and the host was available.
- Check the job log and its exit status.
- Check upstream dependencies such as databases or third-party APIs.
- Decide whether rerunning the job is safe. Some billing or export jobs can create duplicates.
- Record the outcome and fix the cause.
Test the alert deliberately by pausing a noncritical job or using a test heartbeat. You should know who receives the notification and how long it takes to arrive.
Bryzora’s cron job monitoring can alert when an expected heartbeat is missed. Add your most important background task first, then expand coverage as your runbooks mature.