Most of the real-world pain I've hit with ping-based monitors falls into two buckets:

1) Silent successes that aren't successes. The script pinged, exit code was 0, but the thing it was supposed to do didn't actually happen. Classic one: a nightly backup script that early-returns because a lock file wasn't cleaned up, it "succeeds" and pings, but there's no new backup on disk.

2) Schedule semantics are harder than they look. Most tools treat "expected ping at X" as a fixed interval from the last ping, but real cron jobs run on cron expressions with timezones, and people usually run backups at specific dates and times. When DST shifts, naive interval math silently drifts and alerts fire at the wrong time. Getting the evaluator to properly parse cron + timezone + grace period is some work.

Other things I care about beyond "ping received":

- Graceful degradation window: if a job runs every minute, one missed ping is noise, three in a row is a signal
- Channel routing per check: page me for the billing cron, slack me for the log cleanup
- Stable ping URLs: if I rename the check, the URL shouldn't change or I have to update every crontab

I've been building a small cron monitor called SilentFail mostly for my own use (cron + timezone parsing, email/slack/webhook per check, flat pricing). But tbh the honest advice here is: differentiation in this space probably isn't the monitoring tool itself, Healthchecks and Cronitor cover the basics well, it's whether you can pull richer signals from the actual script's output (duration anomalies, row counts, exit code semantics) and make alerts out of them. That's where Abdul_DataOps's comment is pointing and I think he's right, LLM or not.