Choose a cron monitoring service by the failure you need it to detect: no scheduled start, no successful completion, an explicit failure, or a job that runs too long. Cronitor and Healthchecks.io expose job lifecycle signals; Better Stack supplies heartbeat monitoring within its incident workflow; Dead Man’s Snitch distinguishes fixed-window and learned check-in behavior; Oh Dear connects scheduled-task checks to monitored sites and servers. These are meaningfully different monitoring contracts.
Our original timing analysis shows why a green check-in is insufficient evidence of a healthy schedule. Two nonempty hourly windows can conceal a 118-minute gap, and a normal seven-minute job can violate a five-minute completion allowance. We also enumerated the two UTC instants represented by a repeated local time during a daylight-saving transition. These are local calculations, not measured vendor alerts.
Compare the monitoring contract
| Service | Documented control to examine | Decision-changing qualification |
|---|---|---|
| Cronitor | Job lifecycle, schedule, duration assertions and grace | Grace also changes the effective duration-assertion boundary |
| Healthchecks.io | Simple or cron schedule; start, success and fail signals | Grace also limits time from start to success |
| Better Stack | Heartbeat frequency, grace and on-call escalation | A new heartbeat remains pending until its first request |
| Dead Man’s Snitch | Heartbeat fixed windows or Smart Alerts | One ping per window is not a maximum-gap guarantee |
| Oh Dear | Frequency or cron expression, timezone and grace | Bulk sync removes job definitions omitted from its input |
Three timing traps we calculated
Our two hourly windows both passed while the gap between pings was 118 minutes. Put one success at minute 1 and another at minute 119. The windows [0,60) and [60,120) each contain a success. Under a different, explicitly elapsed-time contract with a 60-minute period and five-minute grace, the next success was due at minute 66. The second ping would be 53 minutes beyond that deadline. Fixed windows and elapsed time answer different questions.
Next, we modeled a job that starts at 01:00 and legitimately finishes at 01:07. A completion deadline of 01:05 is too short by two minutes. An eight-minute allowance ends at 01:08 and accepts this example, but also allows a silent runtime failure to persist longer. Increasing grace is therefore a detection tradeoff, not a free reduction in false positives.
Finally, Python’s timezone database mapped October 25, 2026 at 02:30 in Europe/Belgrade to both 00:30 UTC and 01:30 UTC, using the two fold values. That establishes an ambiguous wall-clock input. It does not tell us whether any vendor or your scheduler skips, duplicates or otherwise handles that run. Verify the scheduler’s rule and the monitor’s rule together.
pings = [1, 119]
windows_pass = [any(start <= p < start + 60 for p in pings)
for start in (0, 60)]
elapsed_deadline = pings[0] + 60 + 5
assert windows_pass == [True, True]
assert pings[1] - pings[0] == 118
assert pings[1] - elapsed_deadline == 53Cronitor
The Monitor API reference distinguishes job and heartbeat schedules, grace, explicit failures and duration assertions. Its current documentation says grace also adds time to a job’s maximum-duration assertion. A configured five-minute duration threshold and a separate grace value should therefore not be read as an unconditional alert exactly five minutes after starting.
The Telemetry API provides run, complete and fail signals, and a series identifier for associating a job invocation. This is worth examining when several runs can overlap. A job-specific lifecycle is more informative than reusing one undifferentiated heartbeat for multiple workers.
Cronitor is a candidate when lifecycle and assertion rules need to be explicit. Check the API-version-specific schedule shape and actual status after initialization. Its pricing separately accounts for monitored resources and users; a free monitor count is not equivalent to every paid alerting entitlement.
Healthchecks.io
The Healthchecks.io documentation explains simple elapsed schedules and cron schedules separately. With a simple schedule, lateness follows the last success plus the period. With cron, the expected wall-clock occurrence supplies the reference point. Optional start signals add runtime measurement, but grace also sets the maximum allowed interval from start to success.
This shared setting matters in our seven-minute scenario. A grace value suitable for small scheduling jitter may be too short for legitimate execution. Model both late startup and runtime before adopting one value. Failure signaling can report a nonzero exit or an explicit failure without waiting for a missing success.
Healthchecks.io suits a team that wants these scheduling semantics documented directly. Review job counts, retained log entries and notification credits separately. We did not test hosted escalation, and an exit-code signal still cannot prove business output correctness.
Better Stack
Better Stack’s heartbeat guide defines expected frequency plus grace and connects a missed heartbeat to on-call incident escalation. It also says a newly created heartbeat stays pending until its first request. Provisioning a check is therefore not evidence that its intended runtime has initialized it.
For the elapsed-time requirement in our scenario, use a heartbeat emitted only after useful work succeeds. A generic liveness loop could keep sending pings while the actual export is stuck. Confirm initialization from the real job, then inspect what happens when that job stops reporting. Do not infer a separate per-run runtime assertion from the frequency-and-grace guide alone.
This is a relevant option when the team already wants monitoring and response together. The commercial model includes responder licensing and monitoring allowances; check heartbeat capacity and the selected notification scope rather than comparing only team-member counts.
Dead Man’s Snitch
The official FAQ distinguishes Heartbeat Alerts, which examine fixed time windows, from Smart Alerts, which learn check-in timing. The fixed-window definition is precisely the kind of contract our 118-minute-gap example examines. It can be appropriate when the requirement is one successful batch within each period, rather than a strict maximum interval between completions.
Choose the mode deliberately. Smart Alerts are not measured in our model, and we do not assign them a synthetic alert time. The FAQ also describes Error Notices and plan-dependent availability. Explicit failure reporting and absence monitoring solve different detection delays.
The current plan list separates basic and enhanced intervals and places Error Notices on Surveillance Van. An interval or error capability visible in documentation should not be assumed present on the smallest plan. This service is a useful candidate for simple check-ins when its selected timing contract matches the job.
Oh Dear
Oh Dear’s cron monitoring API supports simple frequency checks or cron expressions with a server timezone and grace. Definitions attach to a monitored resource. For an agency or application team organizing jobs around sites and servers, that resource model may fit the way ownership already works.
Its provisioning contract deserves attention: bulk sync is documented as destructive for definitions omitted from the submitted list. A deploy pipeline that knows about only one application’s jobs must not replace another application’s definitions under the same monitored resource. This is a configuration-ownership issue that a timing-only comparison misses.
Keep a complete owned definition set or use targeted updates, and review repeated-hour behavior with the actual scheduler. Compare site-and-server plan capacity alongside task monitoring, rather than equating the headline resource count with another service’s per-job count. We did not call the management API.
Methodology and limitations
Toolverly Editorial checked the linked official documentation and plan pages on October 18, 2026. Python 3.14.6 on macOS executed the fixed-window, elapsed-deadline, runtime and timezone calculations. We retained the inputs, code and results. The model’s thresholds are stated explicitly and are not a simulator of any complete vendor implementation.
We did not create monitors, send check-ins, trigger alerts or test vendor latency, daylight-saving behavior, escalation delivery or reliability. We also did not test whether a completed job produced correct business data. AI assistance was used for research, code and writing; outputs and source claims were reviewed before publication. Read about Toolverly Editorial.
Choose the contract first, then its configuration and commercial package. For externally requested pages use our website uptime comparison; for the people coordinating a failure use our incident management comparison. A successful homepage request cannot establish that last night’s scheduled work completed.
Photo by Kevin Ache on Unsplash. Read about our publication or send a correction.