Heartbeat & cron job monitoring
Ping SitePuls when a scheduled job finishes. If the ping stops, you get an alert — ideal for backups, imports, and internal automations that must run on time.
For cron schedules and missed-run detection, see Cron job & missed-run monitoring.
Contrast heartbeats with host ping and automation webhooks: Ping (ICMP) host monitoring · Webhook alerts for incidents · Monitor tags & public status page filters
What heartbeat monitoring is for
Cron and background workers can fail silently while the website still loads. A heartbeat is a simple “I ran” signal after your job completes so you know the schedule is healthy.
How the check works
SitePuls gives you a unique URL. Your script calls it with curl or any HTTP client after success. If no request arrives within the expected window (plus grace), the monitor goes down and alerts fire.
Jobs and automations to watch
Database backups, nightly data syncs, cleanup tasks, report generation, and queue drainers — anything that must run on a cadence even when nobody logs in.
Alert when heartbeats stop
Email, Telegram, and webhooks carry the same incident signals as other monitors. History shows missed windows so you can prove reliability to your team.
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.
What to monitor with heartbeats
- 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 heartbeat alert
Heartbeat missed: nightly-backup did not ping within the 30-minute window
No agent required
Everything is an HTTP call from your existing environment — VMs, containers, or serverless functions — as long as outbound HTTPS is allowed.
Pair with API monitoring
API checks validate user-facing endpoints; heartbeats validate batch work behind them. Together they cover synchronous and asynchronous paths.
Internal tasks and pipelines
Use heartbeats for jobs that don’t map cleanly to a public URL. The monitor only cares that your automation checked in.
Setup checklist
Create the monitor, copy the URL, add it to the end of your cron or workflow, set interval + grace to match runtime, and attach contacts.
Frequently asked questions
What is heartbeat monitoring?
Heartbeat monitoring checks whether a scheduled job reports in on time.
What can I monitor with heartbeat checks?
You can monitor cron jobs, backups, workers, imports and scheduled scripts.
What happens when a heartbeat is missed?
SitePuls can alert your team so you know the job stopped running or reporting.
What if my job is slower than the interval?
Increase the expected interval or grace period so occasional long runs don’t false-positive. Tune to your worst-case runtime.
Can serverless functions send heartbeats?
Yes, as long as the function can call the HTTPS URL when it completes.
Is this a replacement for log-based alerting?
Heartbeats answer “did the job run on schedule?” Logs answer “what happened inside?”. Many teams use both; SitePuls focuses on the heartbeat signal.
Can I reuse one URL for multiple jobs?
Each monitor has its own URL so you can tell which pipeline failed. Split separate cron tasks into separate monitors.
What about jobs that should not run concurrently?
Heartbeats only prove completion. Serialize jobs in your scheduler if exclusivity matters — SitePuls does not coordinate locks between runs.