Heartbeat monitoring verifies that a scheduled process completed within an expected time window. The process sends a signal after it runs; when the signal does not arrive on time, the monitoring platform alerts the responsible team.
This is useful because many scheduled-job failures are silent. The website may remain online while billing, backups, data imports or reports stop running in the background.
Key takeaways
- Send a heartbeat after successful completion, not only at job start.
- Set the expected schedule and grace period explicitly.
- Monitor business-critical jobs before low-impact maintenance tasks.
- Give each missed heartbeat an owner and runbook.
- Test failure alerts deliberately.
- Use application logs alongside heartbeat monitoring to diagnose the cause.
What is heartbeat monitoring?
Heartbeat monitoring is an external check for scheduled processes.
A job sends a request or signal to a unique monitoring endpoint when it completes. The monitoring service expects that signal according to a schedule.
If the signal is late or missing, the monitor creates an alert.
The pattern is sometimes described as a dead man’s switch because silence indicates a possible failure.
How does heartbeat monitoring work?
A typical workflow is:
- Configure the expected schedule.
- Configure an allowed grace period.
- Add the heartbeat call to the job.
- Run the job.
- Send the heartbeat after successful completion.
- Alert if the signal does not arrive.
Example shell pattern:
#!/usr/bin/env bash
set -euo pipefail
run_backup_command
verify_backup_command
curl --fail --silent --show-error \
"https://YOUR-APPROVED-HEARTBEAT-ENDPOINT"Store the real heartbeat URL as a secret. Do not publish it in public documentation or source repositories.
Why are scheduled jobs difficult to monitor?
A scheduled job can fail without affecting the main website immediately.
Examples:
- Cron daemon stopped.
- Server reboot changed scheduling.
- Job crashed.
- Dependency timed out.
- Credentials expired.
- Disk filled.
- Job started but never completed.
- Lock file prevented execution.
- Queue worker stopped.
- Job completed partially.
- Deployment removed the schedule.
A standard uptime monitor may still report that the application is online.
Heartbeat monitoring versus uptime monitoring
| Heartbeat monitoring | Uptime monitoring |
|---|---|
| Expects a signal from a process | Sends a request to a service |
| Best for scheduled jobs | Best for websites and APIs |
| Detects silence or lateness | Detects failed or slow responses |
| Depends on job instrumentation | Can be external and agentless |
| Schedule-aware | Interval-based |
Use both when a service has public endpoints and background jobs. See the Uptime Monitoring Guide.
Which jobs should be monitored first?
Prioritise jobs whose failure affects money, data, access or recovery.
High-priority examples:
- Subscription billing.
- Invoice generation.
- Account provisioning.
- Backups.
- Data imports.
- Webhook retries.
- Usage aggregation.
- Trial expiry.
- Security synchronisation.
- Customer report generation.
- Email or notification queues.
Low-impact cleanup jobs can be added later.
Should the heartbeat be sent at the start or end?
Send the success heartbeat after the required work completes.
A start-only heartbeat proves that the scheduler launched the job, not that the work succeeded.
Where supported, use separate signals for:
- Start.
- Success.
- Failure.
- Duration.
If only one signal is available, use it for successful completion and rely on logs for diagnostic detail.
What is a grace period?
A grace period is extra time after the expected completion point before the monitor alerts.
For example:
- Job schedule: every day at 02:00.
- Typical runtime: 20 minutes.
- Grace period: 20 additional minutes.
- Alert if no success signal by 02:40.
Choose a grace period that allows normal variation but still detects a problem early enough to respond.
Review actual runtime history rather than guessing permanently.
How do you monitor long-running jobs?
For long jobs:
- Record start time.
- Record periodic progress where valuable.
- Send success only after completion.
- Set a realistic maximum duration.
- Alert on overdue completion.
- Prevent overlapping runs where unsafe.
- Keep diagnostic logs.
- Track processed-record counts or output validation.
A heartbeat confirms timing. It does not prove the output is correct unless the job validates its result before sending success.
How should backups be monitored?
A backup job should send success only after:
- Backup creation completed.
- Output exists.
- Basic integrity checks passed.
- Remote upload completed where applicable.
- Retention or rotation completed.
Heartbeat monitoring does not replace restoration testing. A backup can complete successfully but still be unusable.
Maintain a separate schedule for test restores.
How should billing jobs be monitored?
Billing jobs require careful design because partial failure can affect customers and revenue.
Monitor:
- Schedule.
- Completion.
- Duration.
- Failure count.
- Number of records processed.
- Retry state.
- Duplicate protection.
- Downstream provider response.
Do not automatically rerun a billing process without idempotency and duplicate-charge protection.
A missed heartbeat should route to the owner of the billing workflow, not only a general infrastructure inbox.
How should data imports be monitored?
For an import:
- Send success after parsing and persistence.
- Validate expected file or record counts.
- Distinguish “no data expected” from “input missing”.
- Track partial errors.
- Monitor upstream delivery.
- Set a grace period based on the actual delivery window.
A successful process with zero imported records may still represent a business failure.
How should agencies use heartbeat monitoring?
Agencies can monitor scheduled jobs when they are inside the agreed support scope.
Examples:
- Client backups.
- Product-feed imports.
- Scheduled content sync.
- Reporting jobs.
- Ecommerce integrations.
- Data exports.
Before enabling alerts, document:
- Who owns the job.
- Who can access the system.
- Whether the agency is authorised to rerun it.
- Whether remediation is included.
- Client communication threshold.
Do not monitor jobs the agency cannot identify or support without a clear escalation route. See Website Monitoring for Agencies.
How should SaaS teams use heartbeat monitoring?
Small SaaS teams should focus on jobs tied to:
- Revenue.
- Customer lifecycle.
- Data consistency.
- Recovery.
- Integrations.
- Compliance operations.
A simple heartbeat can provide high value before a full job orchestration or metrics platform is introduced. See SaaS Monitoring Without a DevOps Team.
What should a missed-heartbeat alert contain?
Include:
- Job name.
- Environment.
- Expected schedule.
- Last successful completion.
- Current overdue duration.
- Runbook link.
- Owner.
- Logs or dashboard link.
- Whether rerunning is safe.
- Escalation contact.
Do not expose the secret heartbeat URL in the alert.
How do you test heartbeat monitoring?
Testing is essential.
- Configure a test job.
- Confirm a success signal is recorded.
- Stop or skip the job.
- Confirm the alert arrives.
- Confirm the correct owner receives it.
- Confirm recovery behaviour.
- Test a delayed job.
- Test a failed job that does not send success.
- Document the result.
Repeat testing after changing schedules, secrets or infrastructure.
Common heartbeat-monitoring mistakes
Sending success before completion
This hides failures that occur during the job.
Using one heartbeat for multiple jobs
The monitor cannot identify which job failed.
Setting a grace period that is too large
Detection arrives too late to protect the business process.
Setting a grace period that is too small
Normal runtime variation creates noise.
Ignoring time zones and daylight-saving changes
Use explicit scheduling and confirm how the scheduler behaves.
Not rotating exposed heartbeat URLs
Treat heartbeat endpoints as secrets because an unauthorised caller could create false success signals.
Monitoring execution but not output
Validate the result before sending success.
Heartbeat monitoring checklist
- Critical scheduled jobs inventoried.
- Job owner assigned.
- Expected schedule documented.
- Typical runtime measured.
- Grace period configured.
- Success signal sent after validation.
- Secret endpoint stored securely.
- Alert contacts tested.
- Runbook linked.
- Safe rerun behaviour documented.
- Failure test completed.
- Time-zone behaviour reviewed.
- Backup restoration tested separately.
- Job output validated.
Frequently asked questions
What is a dead man’s switch?
It is a monitoring pattern where the absence of an expected signal triggers an alert. Heartbeat monitoring applies this pattern to scheduled processes.
Can heartbeat monitoring detect a job that partially failed?
Only if the job withholds the success heartbeat when validation fails, or sends a distinct failure signal where supported.
Should every cron job have a heartbeat?
Prioritise jobs with customer, revenue, data or recovery impact. Low-value jobs can be added when the operational benefit justifies the maintenance.
Can a heartbeat endpoint be called from any programming language?
Usually yes, provided the environment can make the required network request. Use the implementation approved by the monitoring platform.
Is a successful heartbeat proof that a backup works?
No. It can prove that the backup job and validation steps completed. Restoration testing is still required.
Does Sentinel support heartbeat monitoring?
Sentinel’s homepage states that users can add HTTP, DNS or Heartbeat (Cron Jobs) configurations.
Detect silent job failures
Background jobs deserve the same operational ownership as public endpoints. Add a completion heartbeat to critical processes, choose realistic grace periods and test the alert path.
Know when a scheduled job stops reporting.
Review the current monitoring options on Sentinel pricing.