The site looks normal, but wp-cron not running breaks the jobs you do not see

The frustrating part of wp-cron not running is that the front of the site can look completely fine while important background work quietly stops. Pages still load. Menus still work. You may even be able to log in and publish a post manually. Meanwhile, scheduled posts miss their publish time, backups do not start, plugin update checks stall, and routine cleanup tasks pile up in the background.

This is why the problem is easy to miss. WordPress does not run scheduled tasks like a traditional server cron by default. Instead, it tries to trigger them when someone loads a page. That means a site can appear healthy simply because a visitor happened to arrive at the right moment and kicked pending tasks forward. A quick spot check can fool you into thinking everything is fine, even though the site has no reliable timing behind it.

A practical way to judge whether this is becoming a real issue is to look at how late scheduled events are. An event that is more than 1 hour overdue is a warning sign. An event that is more than 6 hours overdue is no longer a minor delay; that is a failure. The same logic applies to queue-based jobs used by many plugins. An Action Scheduler backlog of 25 past-due jobs is a warning, and 200 past-due jobs is a failure.

Those numbers matter because they separate a harmless delay from a broken process. One late task after a traffic lull is different from hours of drift or hundreds of overdue jobs. The actual symptom most site owners notice is not a server error. It is a pattern: missed schedules, stale updates, delayed emails, and admin notices that never seem to clear even though the site itself still loads normally.

Why the obvious check often misses the problem

The most misleading part of WP-Cron is that a single successful run does not prove the system is healthy. Because WordPress often triggers scheduled work during page loads, the cron queue may process only when somebody visits the site. If you check right after loading a page, you may see no overdue tasks and assume everything is working. In reality, the site may have gone hours without running anything until that one visit happened.

That is why a site with no system cron runner at all deserves attention on its own. Even if the queue happens to be empty at the moment you look, that healthy reading may only mean a human visit just woke the system up. It does not mean there is dependable scheduling in place. Reliable sites need background tasks to run on time whether or not anyone is actively browsing.

This also explains the common pattern where low-traffic sites suffer more visible cron issues than busy ones. On a high-traffic site, repeated visits may hide the weakness by constantly nudging tasks along. On a quieter site, there may be long gaps between page loads, so scheduled jobs drift further and further behind. The site owner then sees random-looking failures: a post misses its publication time overnight, backups fail on weekends, or update checks seem inconsistent.

The better test is not “Did cron run once?” but “Is there a reliable mechanism making it run on schedule?” Then look for evidence of drift. Are there events overdue by more than 1 hour? More than 6? Is the Action Scheduler queue building up past 25 or even 200 past-due jobs? Those are operational signs of a timing problem, not just a temporary hiccup. Without that deeper check, WP-Cron can fail silently for a long time while the site appears normal on the surface.

How to tell whether wp-cron is actually not running

Start with the symptoms you can observe, then confirm them with timing and backlog checks. The most common visible signs are:

• Scheduled posts miss their publish time and only go live after someone logs in or manually updates something.
• Backups or cleanup tasks do not happen on schedule, even though the backup plugin itself still appears active.
• Plugin and theme update checks lag behind, so the dashboard looks stale or inconsistent.
• WooCommerce or other plugin queues build up, often showing delayed emails, subscriptions, webhooks, or order-related actions.

Next, check whether scheduled events are overdue. A few minutes late is not usually meaningful. What matters is whether tasks are consistently missing their expected time by enough to indicate drift. Use these thresholds:

• More than 1 hour overdue: warning
• More than 6 hours overdue: failure

Then check queue-based jobs, especially Action Scheduler, which many plugins rely on. A growing backlog here is one of the clearest signs that background processing is not keeping up:

• 25 past-due jobs: warning
• 200 past-due jobs: failure

Finally, answer one more question: is there a system cron runner in place at all? This matters even if current overdue counts look fine. Without a system-level trigger, the site is still depending on page views to run scheduled work. That means a “healthy” result can be accidental and temporary. In practice, the combination that most strongly indicates a real problem is this: no system cron runner, occasional healthy-looking checks, and recurring missed schedules. That is the classic silent failure pattern—tasks only run when someone happens to visit, not because the site has dependable scheduling.

What causes WP-Cron to stop or fall behind

There is rarely just one cause. More often, WP-Cron falls behind because the site is relying on a fragile trigger and then one or two extra issues make the delay visible. The first and most important cause is simple: no reliable system cron runner. In that setup, scheduled tasks only get a chance to run during page loads. If traffic is light, jobs wait. If traffic stops overnight, they wait longer.

Beyond that, several conditions can make the backlog worse:

• Long-running or stuck tasks can block later jobs from clearing quickly, especially in plugin queues.
• Heavy plugin activity can create more scheduled work than the site processes in time, leading to an Action Scheduler backlog.
• Server or PHP timeouts can interrupt background jobs before they finish, so the same work remains due.
• Loopback or internal request problems can prevent WordPress from triggering its own scheduled processing reliably.
• Low-traffic periods expose the weakness of page-load-based scheduling, making missed tasks much more obvious.

One reason this confuses site owners is that the cause is often indirect. A plugin may appear to be “failing,” but what is really failing is the timing mechanism that plugin depends on. A backup plugin that misses its schedule may not be broken at all. It may simply never be getting the scheduled trigger it expects. The same applies to delayed emails, stale update checks, and missed post publication.

This is why it helps to think in terms of system behavior, not isolated symptoms. If you see one missed post, that could be a one-off. If you see events more than 1 hour overdue, queues with 25 or more past-due jobs, or anything drifting beyond 6 hours or 200 jobs, the issue is bigger than a single plugin. At that point, the site is not just delayed. Its background job system is unreliable.

How to fix it and verify the fix actually holds

The most dependable fix is to make sure scheduled tasks run from a system cron runner instead of depending on page visits. That gives the site a predictable heartbeat whether traffic is high, low, or completely absent for a while. Without that, you can clear a backlog today and still have the same problem return the next time the site has a quiet period.

After putting a reliable trigger in place, work through the queue and confirm that tasks are catching up:

1. Check overdue scheduled events. Anything over 1 hour late is still a warning. Over 6 hours means the fix is not complete or the backlog is not clearing.
2. Review Action Scheduler jobs. If there were many past-due jobs, watch whether the count drops steadily. Under 25 past-due jobs is a much better sign than a queue that keeps climbing.
3. Look for recurring offenders. If the same task stays overdue, that may point to a plugin-specific job failure rather than a general cron trigger problem.
4. Test the real symptoms. Confirm that scheduled posts publish on time, backups run when expected, and update checks refresh normally.
5. Recheck during low-traffic hours. This is the part many people skip. A system that only looks healthy after manual activity is not really fixed.

The key is to verify stability, not just one successful run. A single clean dashboard right after you load the site proves very little. What you want is consistency over time: no events drifting past the 1-hour warning threshold, no failures stretching beyond 6 hours, and no Action Scheduler backlog growing toward 25 or 200 past-due jobs again.

Once those numbers stay under control even when nobody visits the site, you know WP-Cron is not just waking up occasionally. It is actually running the way it should.