"WP-Cron not running" and "cron job failed WordPress" are two of the most-searched WordPress problems there is, and a lot of the advice you'll find is chasing a bug that isn't really there. Here's the part almost nobody explains clearly: WP-Cron isn't a cron job at all. It's a WordPress feature that just happens to share the name, and understanding the difference explains most of the confusion.
What "cron" actually means (the real one)
A real cron job is a task your server's operating system runs on a fixed schedule, driven by the system clock — "every day at 2am, run this script," full stop, regardless of whether anyone visits the website. It doesn't need traffic. It doesn't need PHP to be loaded. It just runs, because the OS itself is watching the clock.
What WP-Cron actually is
WordPress doesn't have access to your server's real system cron by default (most shared hosting doesn't give ordinary users that kind of access), so it built its own workaround: every time a page on your site loads — a visitor, a bot, an API request, anything that triggers WordPress to boot up — WordPress checks a stored list of scheduled tasks and asks "is anything due right now?" If something is due, it runs it (or dispatches a background request to wp-cron.php to run it) as part of, or right after, that same page load.
That single design choice is the source of almost every "WP-Cron isn't running" report you'll ever see. WP-Cron doesn't run on a clock. It runs on traffic. No traffic, no check, no chance for anything scheduled to fire — even though nothing is actually broken.
Why this makes "is my cron broken" surprisingly hard to answer
Picture two completely different sites with the exact same symptom: a scheduled task hasn't run in six hours.
- Site A is a busy store with thousands of visits an hour. Six hours of silence on a scheduled task is a real red flag — something is actually stopping WP-Cron from firing despite constant traffic.
- Site B is a niche blog, or a staging site, or a B2B tool that only gets visits during business hours in one time zone. Six quiet hours overnight is completely normal. Nothing is broken; nobody happened to load a page.
A monitoring tool that only checks "how long since the last tick" and alarms past a fixed threshold will misjudge Site B constantly. That's the exact failure mode that's most common in "cron checker" plugins, and it's why so many site owners either ignore the alerts entirely (defeating the point of monitoring) or waste time investigating a problem that was never there.
| Situation | What it usually means |
|---|---|
| Heartbeat is stale, but the site has had no real visitors either | Normal. Nothing has triggered WP-Cron to check in. |
| Heartbeat is stale despite genuine recent traffic | A real problem — something is preventing WP-Cron from running or completing. |
| A specific task fired a bit later than scheduled, once | Normal. WP-Cron only checks on page load, so exact timing always drifts a little. |
| A specific task never fires at all, across many opportunities | A real problem with that task's schedule or the plugin that registered it. |
The fix for sites where this actually matters
If your site genuinely needs scheduled tasks to run on a predictable clock regardless of traffic — an online store processing abandoned-cart emails, a membership site billing renewals — the standard fix is to stop relying on visitor-triggered WP-Cron entirely. Add define('DISABLE_WP_CRON', true); to wp-config.php, then set up a real system cron job (through your host's control panel, or a server-level crontab) to hit wp-cron.php on a fixed schedule — typically every 5 to 15 minutes. That gives you the reliability of a real cron job without giving up WordPress's own task-scheduling API.
If your site doesn't have that kind of urgency, the default visitor-triggered behavior is genuinely fine — it just means the right question to ask isn't "how long has it been," it's "is this actually a quiet site, or is something actually stuck."
How to actually tell the difference, without guessing
This is the exact problem we built Cron Verdict to answer. It watches two separate signals instead of one: whether WP-Cron has run recently at all (the heartbeat), and whether each individually scheduled task fired within a reasonable grace window of when it was actually due. That combination is what lets it say "this is just a quiet site" instead of crying wolf on every low-traffic day — and still catch it immediately when a task genuinely goes silent on a site that's clearly getting visitors.