Monitor cron jobs when silent failures are not an option
Cron jobs don’t send push notifications when they fail—they just stop running. Heartbeat monitoring gives you a unique URL to ping when a job finishes; if the ping doesn’t arrive in time, SitePuls opens an incident and alerts your contacts.
Why cron fails silently
Exit codes go to logs nobody reads; disks fill; credentials expire; scheduler clocks drift. Users only notice when downstream data stops updating.
What a heartbeat actually is here
An HTTP request from your script to SitePuls after successful work. No daemon to install—curl or any HTTP client at the end of the job.
Missed heartbeat = missed execution
If you expect a job every hour, configure the expected interval and grace. No ping in that window means the monitor goes DOWN and notifications fire.
Examples: backups, syncs, reports
Nightly database dumps, ETL pulls, invoice generation, cache warming—anything that must run on a cadence even if no one logs in.
Why this pairs with API monitoring
API checks validate the online surface; heartbeats validate batch work that feeds the system. Together they cover sync and async paths.
Serverless and containers
If your function can call HTTPS when it completes, it can send a heartbeat.
Tuning intervals and grace
Long jobs need longer windows; otherwise you’ll alert during normal runtime. Set grace to absorb variance.
What SitePuls doesn’t do
It doesn’t coordinate distributed locks between jobs or replace log-based debugging—it tells you the schedule failed from the outside.
What you can verify with SitePuls here
- Cron-style reliability uses heartbeat monitors: your task calls a unique URL when it finishes successfully.
- If the call does not arrive inside the expected interval (including grace), SitePuls marks the heartbeat monitor as failed.
- No agent install is required—only an outbound HTTPS request from your existing environment.
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.
FAQ
Is this the same as /heartbeat-monitoring?
Yes—this page explains the cron use case for the same heartbeat feature.
One URL for multiple jobs?
Use separate monitors per job so you know which pipeline failed.
Alert channels?
Email, Telegram, and webhooks.
Can jobs overlap?
Serialization is your scheduler’s job; SitePuls only sees whether a ping arrived in the window.
What if my job is slower than the interval?
Increase interval or grace to match worst-case runtime.
Do you run my cron for me?
No—SitePuls only receives pings; your infrastructure still schedules work.
Can I monitor Windows Task Scheduler?
Anything that can HTTP GET/POST the heartbeat URL on completion works.
How do I start?
Create a heartbeat monitor, copy the URL into your script, set interval and contacts.