WP-Cron Is Not a Clock: Why Scheduled WordPress Jobs Can Run Late
WP-Cron is traffic-triggered by default. Learn how to inspect scheduled jobs, spot overdue events, and make critical WordPress automation more reliable.
A post is scheduled for 8:00 a.m. At 8:17 it is still marked “scheduled.” The overnight backup should have run, a shop automation is lagging behind, and a plugin suddenly reports a missed schedule.
The usual response is: “But the cron job is configured.”
With WordPress, that is exactly where the terminology can become misleading. WP-Cron is not a continuously running system cron. By default, WordPress checks on page loads whether scheduled tasks are due. If nobody visits at the intended time, an event may not be triggered until a later request arrives.
For a small content site, that can be perfectly adequate. For stores, memberships, newsletters, imports, backups, or time-sensitive publishing, it should not be mistaken for a timing guarantee.
What WP-Cron actually does
WordPress uses WP-Cron for time-based tasks. Core features such as update checks and scheduled posts use it, and plugins commonly attach their own jobs to the same system.
The important difference from a traditional system scheduler is that WP-Cron does not run continuously in the background. On page load, WordPress checks which events are due. WordPress documentation gives the straightforward example that an event intended for 2:00 p.m. may not run until 5:00 p.m. if no page load occurs before then.
That does not mean WP-Cron is “broken.” It means its execution model needs to be understood and operated according to the job it is expected to do.
Where this becomes an operational problem
1. Low or irregular traffic
A company website may receive almost no visits overnight. A job due at 3:00 a.m. may therefore have no natural trigger at that time.
2. Time-sensitive processes
“Some time after 8:00” is different from “at 8:00.” Scheduled campaigns, product releases, data imports, or external synchronizations may depend on predictable execution windows.
3. Cron is deliberately disabled without a replacement
DISABLE_WP_CRON can be useful when a real system scheduler takes over. It becomes a problem when the setting survives a migration, performance optimization, or hosting change but the external trigger does not.
4. Loopback or HTTP problems
WP-Cron needs to be able to spawn its execution request. Authentication in front of the site, firewall rules, DNS problems, or infrastructure changes can interfere with that mechanism. WP-CLI provides a dedicated test for the spawning system.
5. A plugin leaves stale or overdue events behind
Plugins can register their own hooks. Updates, deactivation, or poor cleanup can leave orphaned or unexpectedly frequent events. WordPress Site Health explicitly tests whether scheduled events are running as intended and notes that failures can also indicate orphaned events left by older code.
The better audit question: not “Is cron enabled?” but “Do the important jobs run?”
A useful WordPress review does not begin with one constant in wp-config.php. It begins with the business processes.
Ask first:
- Which functions actually depend on WP-Cron?
- Which of them can tolerate minutes or hours of delay?
- Which jobs are business-critical?
- Which plugins register their own events?
- Who notices repeated failures?
- Is there an external scheduler, and is its success monitored?
Only then move down into the implementation.
Five concrete technical checks
1. Test the spawn system
WP-CLI can check whether WP-Cron spawning works:
wp cron test
The command checks, among other things, whether WP-Cron is disabled and whether the HTTP request used to spawn cron succeeds.
A successful result is useful, but it does not prove that every individual plugin job completes correctly.
2. Inspect the event list
Run:
wp cron event list
The output includes fields such as the hook, next run time, and recurrence. Pay particular attention to:
- events whose next run is far in the past,
- unexpectedly many instances of the same hook,
- jobs with unusually short intervals,
- hooks belonging to plugins that are no longer in use,
- critical jobs whose schedule does not match the expected process.
3. Take WordPress Site Health seriously
Site Health includes a specific test for scheduled events. Warnings about missed or failing scheduled tasks are not cosmetic admin noise. They indicate that part of the website's automation is not running reliably.
4. Verify the external scheduler
If WP-Cron has been disabled, there must be a documented mechanism that triggers wp-cron.php or due events instead. This may be a hosting control-panel cron or another system scheduler.
“It's in the hosting panel” is not enough. Verify:
- that the task actually runs,
- how often it runs,
- which user executes it,
- which URL or PHP path it calls,
- what happens on failure,
- where logs or exit codes go.
5. Monitor the business outcome
Cron monitoring should not stop at “the trigger ran.” A successful request to wp-cron.php does not automatically prove that a downstream export, email delivery, or API synchronization succeeded.
Critical workflows therefore need an outcome-level check as well: Was the feed updated? Was the scheduled message sent? Did the import arrive? Was the backup created, and can it be restored?
When a system cron makes sense
WordPress itself documents handing WP-Cron to the operating system's task scheduler when tasks need to run on time. A common setup disables page-load triggering with DISABLE_WP_CRON and invokes WordPress cron regularly from outside the request flow.
This is particularly useful when:
- traffic is low or highly variable,
- time-sensitive jobs exist,
- the site has many scheduled events,
- hosting and monitoring are managed professionally,
- execution should be deliberately decoupled from visitor traffic.
The order matters: configure and test the replacement first, then disable the built-in trigger. Doing it backwards can turn a performance tweak into a silently disabled scheduler.
What Website-Pflichtencheck would inspect
A WordPress operations review should cover more than plugin versions and visible errors. We would look at which scheduled processes exist, whether WP-Cron can be spawned reliably, whether events are overdue or suspiciously duplicated, whether an external scheduler is configured correctly, and how critical jobs are monitored.
That includes the boundary between application and infrastructure: hosting, loopback requests, wp-config.php, WP-CLI, plugin hooks, logs, and the actual outcome of important automations.
A website can pass every uptime check and still be an hour late to work every morning.
A small test for today
On a WordPress site where you have maintenance access, inspect the scheduled events and answer three questions:
- Which scheduled job matters most to the business?
- When did it last complete successfully?
- Who would notice if it did not run tomorrow?
If question two or three can only be answered with “it probably does,” there is no reason to panic. There is, however, a very good candidate for the next technical maintenance review.