Your uptime monitor says the site is up. It is. Meanwhile the nightly backup hasn’t run since Thursday, the invoice export is halfway through its fourth hour, and nothing anywhere is unhappy about any of it.
Three different monitoring models would have caught those three problems. They are not competing products, and picking one is not the exercise. Picking the right one per job is.
The Short Version
A heartbeat monitoring vs uptime monitoring decision only means anything per job, because each model asks a different question and each is deaf to the others’ failures.
| Model | The question it asks | Catches | Misses |
|---|---|---|---|
| Uptime | Does this URL answer right now? | Outages, TLS failures, error pages, slowdowns | Anything that doesn’t serve HTTP |
| Cron | Did the job run when the schedule said it would? | Missed runs, hung jobs, explicit failures | Work that has no fixed schedule |
| Heartbeat | How long since this process last said anything? | Silence from always-on workers | A hung job that still pings |
The distinction that matters most is the one the industry blurs. Most vendors use “heartbeat monitoring” and “cron monitoring” as synonyms, because both work by your job sending a ping outward instead of a prober reaching in. The mechanism is shared. What the two do with a missing ping is not.
Uptime Monitoring Watches From Outside
An uptime monitor requests a URL on a schedule and forms a verdict from the response. It is the only one of the three that needs no cooperation from your code, which is why it is where everyone starts.
Its blind spot is structural: it can only see things that speak HTTP on a public address. A queue worker, a nightly report, a data sync, a backup script. None of those serve a URL, so no amount of uptime checking will ever notice them stopping. This is also true of the more elaborate outside-in checks, which is worth reading about separately if you are weighing synthetic monitoring against simpler checks.
Cron Monitoring Knows When the Job Should Have Run
A cron monitor inverts the direction. You tell the monitor the schedule, your job sends a small HTTP ping at start and at completion, and the monitor does arithmetic: if no successful completion arrives by the next expected time plus a grace period, the job is late and an alert fires.
That schedule is the whole value. Because the monitor knows a run was due at 02:00, silence at 02:15 is information rather than ambiguity. In FlareWarden this is configured under a parent uptime monitor (Add Cron Monitor, then set a name, an expected schedule, and a grace period), and the ping URL carries a UUID that acts as its own credential, so there is nothing to install and no inbound firewall rule to open. The cron monitor documentation covers the ping lifecycle in full.
Schedules come in two shapes. A cron expression gives exact next-run calculation for jobs that genuinely follow crontab semantics. A plain interval suits jobs that run every N minutes without caring about wall-clock alignment, and can be anchored to a specific hour and minute when you want “every two days at 03:00” rather than “every 48 hours from whenever it last ran.”
Heartbeat Monitoring Only Knows How Long It’s Been Quiet
Heartbeat is the third mode, and it is deliberately simpler: an interval, a ping, nothing else. It exists for processes that never start and never finish, because they are supposed to be running continuously. A websocket consumer. A daemon. A sync loop.
Here is the tradeoff nobody puts in the comparison tables. A heartbeat has no start-and-complete lifecycle, so it also has no concept of a run taking too long. In FlareWarden, selecting heartbeat mode clears the maximum run duration outright, because there is no run to bound. You trade hung-job detection for the ability to monitor something that has no discrete runs at all.
That trade is correct for a daemon and wrong for a nightly export. If your job has a beginning and an end, use the schedule modes and keep hung-job detection. Reach for heartbeat when the process genuinely has neither.
Where Each One Goes Blind
The useful part of a heartbeat monitoring vs uptime monitoring comparison isn’t the feature grid. It is the failure each model cannot see even when configured perfectly.
- A job that runs, fails, and exits cleanly. If your script swallows its own errors and pings completion anyway, every model above reports healthy. Ping the failure path explicitly, or the monitor is measuring whether cron fired rather than whether the work happened.
- A job that pings before doing the work. Same problem, moved earlier. The ping belongs after the work succeeds, not at the top of the script.
- A hung job under a heartbeat monitor. The process is alive, so it keeps pinging, so the monitor stays green while the queue backs up behind it.
- A site that is up but wrong. Uptime checks confirm a response arrived, not that it contained the right thing. A checkout page serving a 200 with a stack trace in the body passes.
- A job whose host is gone. No host, no ping, so cron and heartbeat monitors both fire. They will tell you the job is late, not that the machine died. Read the alert as a symptom.
The first two are far and away the most common, and they are configuration mistakes rather than product limitations. Every monitoring vendor including us will happily report green while your script quietly catches its own exception.
Setting a Grace Period You Won’t Regret
A grace period is how long past the expected time the monitor waits before calling a run late. Set it too tight and normal variance pages you. Set it too loose and you find out about Tuesday’s failure on Wednesday.
The rule we’d give: make the grace period slightly longer than the job’s worst observed runtime, not its average. A backup that usually takes four minutes and occasionally takes eleven needs a grace period built around eleven. If you don’t know the worst case yet, start loose, watch for a fortnight, then tighten.
Severity is the other half of that dial. Not every scheduled job deserves to mark your whole site as down. A failed payment reconciliation probably does; a cache warmer almost certainly does not. FlareWarden splits this three ways, letting a cron failure mark the parent monitor down, mark it degraded, or notify without touching the parent’s status at all. Use the third setting liberally. It is the difference between an alerting system you trust and one you mute.
What to Run on What
Uptime monitoring on everything with a public URL. That is the baseline and it is cheap.
Cron monitoring on every scheduled job that moves money or data: billing runs, backups, exports, reconciliation, anything whose absence is expensive and silent. Skip it on jobs where a missed run is self-correcting, like a cache warmer that will run again in ten minutes.
Heartbeat monitoring on long-running processes with no natural run boundary, and only those. Platform-specific guides are worth reading alongside this, because the failure modes differ by where the job runs. The traps in Laravel’s scheduler are not the traps in Kubernetes CronJobs, and neither resembles a plain crontab.
Key Takeaways
- They answer three different questions. Uptime asks whether a URL responds, cron asks whether a job ran on schedule, heartbeat asks how long a process has been silent.
- “Heartbeat” and “cron monitoring” are not really synonyms. They share a ping mechanism, but only a schedule-aware monitor can tell you a run was due.
- Heartbeat mode gives up hung-job detection. No start-and-complete lifecycle means no maximum run duration. Correct for daemons, wrong for nightly exports.
- The most common blind spot is self-inflicted. A script that catches its own error and pings success will read green forever. Ping the failure path.
- Size the grace period on the worst run, not the average, and use notify-only severity for jobs that don’t deserve to mark your site down.
Running scheduled jobs nobody is watching? Start monitoring free with FlareWarden — 15 monitors across uptime, cron, and heartbeat checks, no credit card. The cron monitoring feature page has the setup detail.