Heartbeat check-ins when background jobs finish
Give each background task a unique heartbeat URL. Your job sends an HTTP check-in when it finishes; SitePuls watches the expected interval and grace period, opens a DOWN incident on a missed run, and recovers after the next successful check-in — for cron jobs, workers, backups, imports and scheduled scripts.
For cron schedules and missed-run detection, see How to monitor cron jobs (step-by-step).
Contrast heartbeats with host ping and automation webhooks: Ping (ICMP) host monitoring · Webhook alerts for incidents · Monitor tags & public status page filters
How heartbeat check-ins work
Create a heartbeat monitor and copy its unique URL. After a successful run, your script calls that URL (for example with curl or any HTTP client). SitePuls records the check-in and schedules the next due window from your expected interval.
What happens when a check-in is missed
If no request arrives within the expected interval plus grace, the monitor goes DOWN. That missed check-in is the signal that a scheduled or background job stopped reporting — not that SitePuls ran the job for you.
Expected interval and grace period
Set the expected minutes to match how often the job should check in. Add a grace period so longer-than-usual runs do not false-positive. Tune both to your worst-case runtime.
Recovery after the next check-in
When the job starts calling the heartbeat URL again, SitePuls can resolve the open DOWN incident and send a recovery notification through the same alert contacts.
What you can verify with SitePuls here
- Heartbeat monitors expect an HTTPS ping when cron jobs, backups or workers finish.
- Missed heartbeats inside the configured window mark the monitor down.
- Alerts fire when scheduled tasks stop reporting on time.
Where incident alerts can go
- Email addresses saved as alert contacts receive messages when incidents open or resolve (according to your notification settings).
- Telegram notifications via the SitePuls bot after you link a chat to an alert contact (including the bot /start flow for pending contacts).
- HTTPS webhooks that receive JSON with event type, monitor identifiers, status, timestamp, optional incident id, and a short message for generic integrations.
- Slack-compatible incoming-webhook formatting: alert contacts can use a dedicated mode so payloads match Slack-style incoming webhook expectations.
Practical monitoring guide
Example content below is illustrative — values are placeholders, not live customer data.
Jobs that should send check-ins
- Cron jobs and scheduled imports that must finish on time.
- Backup jobs that should report success after completion.
- Background workers and queue consumers.
- Any task where silence means failure even if the website is up.
Setup steps
- Create a heartbeat monitor with the expected ping window.
- Call the heartbeat URL from your job when it completes successfully.
- Attach alert contacts for missed heartbeats.
- Test by skipping one run in a controlled maintenance window.
Example missed check-in alert
Check-in missed: nightly-backup did not hit the heartbeat URL within the 30-minute window
Jobs that can send heartbeat requests
Any automation that can reach HTTPS works: cron entries, queue workers, backup scripts, data imports, report generators, and serverless functions that ping after success.
Heartbeat monitoring vs HTTP uptime checks
HTTP uptime monitors call a public URL on a schedule. Heartbeat monitors wait for your job to check in. Use both when you need website availability and silent batch-job coverage.
Alert channels
Route missed-check-in and recovery notices to email, Telegram, or webhook contacts — the same channels as other SitePuls monitors.
Setup overview
Create the monitor, place the heartbeat URL at the end of a successful job, set interval and grace, attach contacts, then verify with a controlled missed run. For a cron-focused commercial landing, see cron job monitoring.
Frequently asked questions
What is a heartbeat check-in?
A heartbeat check-in is an HTTP request your job sends to a unique SitePuls URL after it finishes, proving the run reported in on time.
How does the heartbeat URL work?
Each heartbeat monitor has its own token URL. A successful GET to that URL updates the last check-in and next due time.
What happens when a check-in is missed?
After expected interval plus grace with no request, the monitor can go DOWN and notify your alert contacts.
What is the expected interval?
It is how often SitePuls expects a check-in. Set it to match the job’s normal cadence.
What is a grace period?
Extra minutes beyond the expected interval before a miss counts as DOWN, so long runs do not false-alert.
What happens after the job starts sending check-ins again?
The next successful check-in can resolve the DOWN incident and trigger a recovery alert.
Which jobs can use heartbeat monitoring?
Cron jobs, workers, backups, imports, reports, and any script that can call the HTTPS heartbeat URL after success.
Which alert channels are supported?
Email, Telegram, and webhook alert contacts — same as other monitor types.