Cron Job & Heartbeat Monitoring
Know when your scheduled jobs stop running.
Cron jobs, backup scripts, data pipelines, and batch processes run silently in the background. When they stop running — due to a cron misconfiguration, a server restart, a permission change, or a code error — there is typically no error, no alert, and no indication that anything has gone wrong. Heartbeat monitoring flips this: your job checks in when it completes, and you're alerted if a check-in is missed.
Silent failures in scheduled jobs
A cron job that stops running produces no output, no error message, and no log entry — it simply doesn't execute. Database backups that haven't run in three weeks. Report generation that failed after a library update. Invoice processing that stopped after a server migration. These are discovered weeks later, often with serious consequences, because there was no system watching for their absence.
Traditional monitoring watches for something going wrong — an error in a log file, a process crashing, a nonzero exit code. None of that helps when the job simply never runs at all. A server that silently lost its crontab entry after a redeploy, a permissions change that quietly broke a script, a typo in the schedule expression that shifted a nightly job to a time nobody's watching — all of these look identical from the outside: nothing happens, and nothing complains.
Heartbeat monitoring inverts the model. Instead of monitoring for failures, you monitor for the presence of a successful completion signal. When a job finishes, it pings a unique heartbeat URL. If that URL isn't pinged within the expected window, NetTests alerts you. Missing jobs are detected immediately — not weeks later when someone notices the output is missing.
What NetTests cron monitoring checks
Every job you monitor gets a unique heartbeat URL — add one line to the end of the script or cron entry that pings it on successful completion. No agent to install, no client library, no changes to how the job itself runs. If the job fails partway through and never reaches that line, no ping arrives, which is exactly the signal you want.
NetTests tracks the expected interval for each job and starts a countdown from the last successful check-in. If the next expected ping doesn't arrive within your configured grace period, an alert fires. The grace period exists because real job runtimes vary — a backup that usually finishes in ten minutes might occasionally take twenty, and a well-chosen grace period avoids false alarms without also masking a genuine failure.
Every check-in is logged with its timestamp, building a complete run history per job — useful for spotting a job that's technically still running but has started taking noticeably longer, often an early warning sign before it fails outright.
Alerts reach your team through email, Slack, Microsoft Teams, or SMS the moment a check-in is missed.
Key features
Heartbeat URLs
Each monitored job gets a unique URL to ping on completion — no agent or client required.
Configurable grace periods
Set how long after a missed check-in to wait before alerting — accommodating variable job runtimes.
Run history
See every heartbeat check-in with timestamp and duration — a complete execution history for every monitored job.
Instant alerting
Receive notifications the moment a job misses its expected check-in window — not hours later.
Runtime trend tracking
Spot a job that's gradually taking longer to complete — often an early warning before it fails outright.
Works with any scheduler
Cron, systemd timers, Windows Task Scheduler, CI pipelines, or anything else that can make one HTTP request on completion.
Unlimited job count
Monitor every scheduled job across every server you operate from a single dashboard.
Multi-channel alerts
Reach your team through email, Slack, Microsoft Teams, or SMS the moment a check-in is missed.
What you'll see
A live look at last check-in times across your scheduled jobs, and the alert that fires when one goes quiet.
Not ready to commit?
Try the free Cron Expression Parser first. Confirm exactly when a cron schedule will actually fire, then set up heartbeat monitoring to confirm the job ran when it should have.
Try the free tool →Free scheduling tool
Frequently asked questions
How does heartbeat monitoring work without installing anything?
You add one line to the end of your script or cron entry — a plain HTTP request (curl, wget, or any HTTP client) to a unique URL NetTests generates for that job. No agent, no client library, no daemon running on your server. If the job completes, the request goes out; if it fails or never runs, it doesn't.
What happens if my job runtime varies?
You set a grace period on top of the expected interval — for example, a job expected every hour with a 15-minute grace period only alerts if more than 75 minutes pass since the last check-in. This avoids false alarms from normal runtime variance while still catching a job that's actually stopped.
Can heartbeat monitoring tell me the job failed partway through, not just that it never ran?
Yes, if you place the heartbeat ping at the very end of the script rather than the start. A job that fails halfway through never reaches that line, so no ping arrives — which looks identical to the job never having started at all, and triggers the same alert either way.
Does this replace logging or error tracking?
No — heartbeat monitoring only tells you whether a job checked in on schedule, not why it didn't. Pair it with your existing logs or error tracking for the "why," and use heartbeat monitoring for the "did it even run," which logging alone can't answer since a job that never starts never writes a log entry.
Can I monitor jobs across multiple servers from one place?
Yes. Every job gets its own heartbeat URL regardless of which server or scheduler runs it, so cron jobs, systemd timers, and CI pipeline steps spread across many machines all show up in the same dashboard.
Start monitoring your cron jobs now
NetTests provides heartbeat URLs for every scheduled job you manage. If a check-in is missed, your team is alerted immediately.
Start monitoring free →