Snagbane Cron Monitor
If your scheduled posts are not publishing, your backups stopped running, or a plugin says its task is “queued” and never gets further, the usual advice is the same everywhere: check whether WP-Cron is disabled, trigger it by hand, install something that pings it once and calls it a day. None of tha
If your scheduled posts are not publishing, your backups stopped running, or a plugin says its task is “queued” and never gets further, the usual advice is the same everywhere: check whether WP-Cron is disabled, trigger it by hand, install something that pings it once and calls it a day. None of that answers the actual question, which is whether your scheduled tasks are really not running, or whether your site is simply quiet.
That distinction is the whole problem. WP-Cron is not a real system cron. It only fires when somebody visits the site, so a low-traffic site naturally goes hours between ticks. That is not the same thing as a backup silently failing for a week — but most cron checkers treat the two identically, and you get either constant false alarms on a quiet site or a real failure nobody notices.
Cron Monitor watches two separate signals instead of one:
- A heartbeat — has WP-Cron actually run recently at all?
- A per-task grace window — did each individually scheduled event fire within a reasonable time of when it was due?
Together those tell “cron is fine, the site is just quiet” apart from “cron is genuinely stuck”, and you get one plain sentence rather than a timestamp to interpret:
- Working — cron ran recently and tasks are firing.
- Running late — a little behind. Often normal on a low-traffic site.
- Not working — the site had visitors, which normally trigger cron, and it still has not run.
- Not enough data yet — just installed, no baseline yet.
- Cannot record anything — the plugin could not create the table it keeps history in, usually a database user without permission to create tables. It says so rather than reporting an all-clear it has no basis for.
A site deliberately running a real server crontab with DISABLE_WP_CRON set is recognised as the healthy setup it is, rather than reported as broken because WordPress is not the one spawning the request.
What you get
- The honest verdict above, on its own admin page and as a dashboard widget.
