Heartbeat monitoring
Cron job monitoring that notices when a job never runs
Cron job monitoring reverses the usual direction of uptime checks: instead of a monitor requesting your service, your scheduled job pings a private URL each time it finishes. MoniterMySite expects that ping at the interval you set, allows a grace period for late runs, and opens an incident and alerts your contacts when the ping fails to arrive.
- One curl command at the end of your job; GET and POST both work, nothing to install
- Expected interval plus a configurable grace period, from zero seconds up to seven days
- Down alert when a ping is missed, recovery alert on the next ping, incident timeline in between
How it works
Create a heartbeat monitor
Add a monitor, choose Heartbeat, and set the expected interval (how often the job should run) and a grace period for runs that are sometimes late; the default is 5 minutes.
Copy the ping URL
Save the monitor and copy its private ping URL from the monitor page. The URL contains a token unique to that monitor; keep it out of public repositories.
Ping when the job succeeds
Call the URL at the end of your job, chained with && so a failed job never reports success. Each ping is recorded as a check and the monitor stays up.
Get alerted when the ping is late
If no ping arrives within the expected interval plus the grace period, the monitor goes down, an incident opens and every attached contact is alerted. The next successful ping resolves the incident and sends a recovery message.
What you get
Works with anything that can make an HTTP request
Cron, systemd timers, CI pipelines, queue workers, serverless functions: if it can run curl, wget or fetch, it can ping a heartbeat.
Grace periods
Jobs that occasionally run late should not page you. Set the grace period to cover the slowest acceptable run, anywhere from 0 seconds to 7 days.
Success-only pings
Because you decide when to ping, a job that runs but exits with an error simply does not report, and is caught the same way as a job that never started.
Same alerting as everything else
Heartbeat incidents go to the same contacts as website outages: email, Slack, Discord, Teams, Google Chat, Telegram, PagerDuty and signed webhooks, by plan.
Pause without noise
Pause the monitor while a job is deliberately disabled. Pings to a paused monitor are accepted and acknowledged, and no incident is opened.
Why scheduled jobs need a heartbeat, not a log
A nightly backup, an invoice run or a report generator fails silently in a way a website never does. If the server reboots and cron does not come back, nothing writes an error anywhere. If the job hangs, the log simply stops. If a crontab edit introduces a typo, the job vanishes without trace. You find out weeks later, when you need the backup.
Heartbeat monitoring (sometimes called a dead man's switch) expects good news on a schedule: the job proves it ran by pinging a URL, and silence is the alarm. Because MoniterMySite only hears from the job when it finishes successfully, a crash, a timeout, a missing dependency and a job that never started all look the same: a missed ping, followed by an alert.
Setting it up in a crontab
The ping is a single HTTP request, so the simplest integration is a curl appended to the existing command, chained with && so it only fires when the job exits successfully. This crontab line runs a backup at 02:00 daily and reports only on success:
0 2 * * * /usr/local/bin/backup.sh && curl -fsS https://monitermysite.com/api/heartbeat/<your-token> > /dev/null
In a CI pipeline the same idea becomes a final step guarded by a success condition, for example a GitHub Actions step with if: success() that runs curl -fsS against the ping URL. GET and POST are both accepted, and the response confirms when the ping was received.
Grace periods, alerting and recovery
The monitor is considered late when the time since the last ping (or since the monitor was created, for a job that has never reported) exceeds the expected interval plus the grace period. The monitor then goes down, an incident is opened, and every attached contact receives a down alert. Heartbeat monitors have no regions or fail thresholds; the schedule is the only judge.
When the next ping arrives, the incident is resolved with its total duration and a recovery message is sent. Maintenance windows apply to heartbeats as well, so a planned period without runs does not count against uptime or page anyone.
Plans and limits
A heartbeat monitor counts as one monitor. Since the job does the pinging, regions do not apply; plans differ in the number of monitors, alert channels and history.
| Plan | Price per month | Monitors | Alert channels | Check history |
|---|---|---|---|---|
| Starter | Free | 10 | Email, webhook | 30 days |
| Launch | $9 ($7.50 yearly) | 100 | Adds Slack, Discord, Teams, Google Chat, Telegram | 6 months |
| Growth | $29 ($24 yearly) | 200 | Adds PagerDuty | 12 months |
| Summit | $79 ($65 yearly) | 1,000 | All eight | 24 months |
Frequently asked questions
What is the difference between a heartbeat monitor and an HTTP monitor?
An HTTP monitor is outbound: our probes request your URL and judge the response. A heartbeat monitor is inbound: your job requests our URL, and we alert when it stops doing so. Use HTTP for anything with an address, and heartbeats for jobs that have no endpoint to check.
How long should the grace period be?
Long enough to cover the slowest run you consider normal, and short enough that you still hear about a problem in useful time. For a nightly job an hour or two usually suits; the default is 5 minutes and the maximum is 7 days.
What if the job runs but fails part-way through?
Chain the ping with && so it only fires when the job exits with success. A job that fails then never pings, and is reported the same way as a job that did not run at all. If you ping unconditionally, the monitor can only tell you the job started.
Can I ping from Windows, a CI pipeline or a serverless function?
Yes. The ping is an ordinary HTTP GET or POST to a URL, so anything with curl, wget, PowerShell, fetch or an HTTP client library can send it.
Is the ping URL secret?
Treat it as one. Anyone who has the URL can mark your job as healthy, so keep it out of public repositories and shared logs. If it leaks, recreate the monitor to get a new token.
Keep reading
Start monitoring in 30 seconds.
Nothing to install. No credit card. 10 monitors free, forever.