What breaks when scheduled WordPress work stops
WordPress cron jobs not running can delay much more than a scheduled blog post. Backups may start late, update checks can drift, form follow-ups may wait, cache cleanup can stop, and a WooCommerce queue can grow while the public site still looks normal.
That quiet failure is why cron problems often survive for days. A homepage can remain fast because it is cached. Meanwhile, background work falls behind. The first useful question is not, “Which cron plugin should I install?” It is, “Did WordPress receive a trigger, did the event enter the queue, and could the responsible task finish?”
At Webless, we separate those three layers before changing a setting. Otherwise, a quick fix can hide the warning while leaving the business task broken.
WordPress cron jobs not running: check three layers
A scheduled task needs a trigger, a queue entry, and working task code. Proving only one layer does not prove that the job completed.
| Layer | What to verify | What failure looks like |
|---|---|---|
| Trigger | WordPress or a server scheduler starts the cron runner | Many unrelated events become overdue together |
| Queue | The expected event exists with a sensible next-run time | The event is missing, duplicated, or scheduled far in the future |
| Task | The plugin or theme callback finishes without an error | One hook keeps failing while other scheduled work continues |
This model keeps the diagnosis focused. A site-wide backlog points toward the trigger. One missing event points toward registration or configuration. One repeating failure usually points toward the task itself.
How WP-Cron actually runs
WP-Cron is WordPress’s scheduler for time-based work. By default, WordPress checks its event list during page loads and calls tasks that are due. It is not a continuously running system service. The WordPress Plugin Handbook explains that time-sensitive sites can connect WordPress to the server’s task scheduler instead.
That difference matters. A quiet site may not receive a page load near the requested time. A busy site can trigger frequent checks even when no task needs to run. Some hosts therefore disable page-load spawning and use a real scheduler at a controlled interval.
However, disabling the normal trigger is only half a configuration. A server scheduler must replace it. When we see the built-in trigger disabled, we verify the replacement before calling the setting correct or broken.
Do not confuse a late event with a broken scheduler
Cron timestamps describe when an event becomes due, not a guaranteed start time. A default page-load trigger may run the event on the first suitable request after that time. A short delay can therefore be normal on a low-traffic site.
The pattern matters more than one timestamp. If events from several unrelated plugins are overdue, investigate the shared trigger first. If most events run but one hook remains late, inspect that task and its dependencies. If jobs finish eventually but a queue grows each hour, the runner may work while lacking enough capacity.
Time zones can also create false alarms. Compare the site’s configured time, UTC, the hosting panel, and any external scheduler before deciding that a timestamp is wrong. Record both the expected run and the observed completion in one time zone.
Finally, check whether the task leaves visible proof. A timestamp that advances can show that WordPress attempted a callback, but it does not prove that an email arrived, a backup completed, or a webhook reached its destination. The business result is the final check.
Start with evidence before changing cron settings
If you find WordPress cron jobs not running, record the current state before forcing anything. A manual run can clear the symptom and remove the timing evidence you need.
Check whether events are actually overdue
List scheduled events and compare each next-run timestamp with the current WordPress time. Look for a pattern. One event a few seconds late during inspection is different from dozens of unrelated jobs that are hours behind.
Also check recurrence. A one-time cleanup event should not be judged like a job expected every minute. The schedule tells you when to wait, when to test, and when a delay has become a real incident.
Confirm how cron gets triggered
Check whether WordPress still starts cron on page loads. If that behavior is disabled, identify the server, hosting panel, or external monitor that replaced it. Confirm the command, interval, working directory, and user account.
Do not assume a line in a hosting panel still runs. Review its last execution result or create a safe heartbeat task in staging. A scheduler entry without execution evidence is only a configuration claim.
Separate WP-Cron from plugin task queues
WooCommerce and other plugins can maintain their own action queues while still relying on WordPress to start processing. A healthy WP-Cron list does not guarantee that every plugin queue is clear. Likewise, a failed plugin action does not prove that the whole scheduler stopped.
Inspect both levels. Compare pending, failed, and completed actions. Then trace the oldest meaningful failure back to the plugin, request, or remote service involved.
Common reasons scheduled tasks fall behind
- No reliable trigger: page-load spawning is disabled, traffic is too low, or the server schedule was removed.
- Loopback requests fail: DNS, TLS, access rules, temporary maintenance protection, or a security layer blocks the site from calling itself.
- A task crashes: a PHP fatal error, missing function, database error, or exhausted resource limit stops one callback.
- The queue is overloaded: a plugin creates tasks faster than the runner can complete them.
- A long task holds the worker: imports, email batches, image processing, or remote API calls take too long.
- The event was never registered: a plugin activation, migration, or update path failed before adding its schedule.
- Duplicate schedules exist: repeated registration creates unnecessary work and makes the queue harder to interpret.
These causes need different fixes. Increasing traffic will not repair a fatal error. A real server cron will not fix a plugin that registers the wrong event. Clearing a queue will not help if the same faulty task recreates the backlog.
Use logs to connect the failure to a task
Time matters when reviewing logs. Match the event’s expected run time with PHP errors, web-server responses, database warnings, and plugin records. This narrows a large log down to the minutes that matter.
A recurring fatal error often identifies one callback. A 401 or 403 response can point to access protection. A timeout suggests a slow dependency or a task that tries to process too much at once. Our error-log monitoring guide explains how to separate repeated risk from harmless background noise.
Do not enable public error display on a live site. Capture errors in a private log, reproduce the task safely, and remove temporary debugging once the evidence is recorded.
Know when a real server cron is the better trigger
A server scheduler is useful when jobs need predictable starts, traffic is irregular, or page-load cron adds avoidable work. It can call WordPress every few minutes regardless of visits. That makes the trigger easier to reason about.
Still, server cron is not automatically faster or safer. The interval must match the workload. The command must run as the right user. Overlapping executions need control. Monitoring must also show whether the call succeeded.
Before switching, test the change in a controlled staging workflow. Then confirm scheduled posts, backups, emails, cache work, and store actions on production after release. Never disable the normal WordPress trigger until the replacement has been proven.
Test cron repairs without creating a second problem
- Record a baseline. Save the overdue events, next-run times, queue depth, and relevant log entries.
- Protect recovery. Confirm that a recent backup can be used through a safe restore test.
- Choose one harmless event. Use a staging-only task or a low-risk maintenance action with a clear result.
- Run one controlled trigger. Avoid repeatedly forcing every due event on a busy live site.
- Check the outcome. Confirm that the event moved, the expected action happened, and no new error appeared.
- Wait for the next interval. A one-time manual success does not prove the automatic trigger works.
This final wait catches many false fixes. If the event succeeds only when someone clicks a button, the task code may be healthy while the scheduler remains broken.
Monitor the next automatic run
A repair is not complete when the backlog disappears. Add a check that notices the next missed run before a client or customer finds the consequence. The check should follow a business result, not only the cron runner.
For a backup job, confirm that a new archive appears, has a plausible size, reaches its destination, and remains restorable. For a scheduled post, compare the intended and actual publication times. For a store queue, watch the oldest pending action and the failure rate rather than the total count alone.
Set the alert window around the real schedule. A five-minute delay matters for an order webhook more than for weekly cleanup. Keep the alert specific enough to act on: name the affected job, the last successful completion, the expected interval, and the first place to inspect.
After the first successful automatic run, check again at the next normal maintenance review. That second observation catches intermittent loopback, resource, and remote-service failures that a single clean interval can miss.
What cron failures look like in a business
The technical warning is rarely the main cost. The business symptom appears somewhere else.
| Visible symptom | Scheduled work to inspect | Proof after repair |
|---|---|---|
| A scheduled post misses its time | Publishing event and site trigger | A new test post publishes automatically |
| Backups show irregular gaps | Backup event, storage connection, and retention job | A fresh archive completes and restores safely |
| Store emails or webhooks wait | Plugin action queue and remote response | A controlled order action completes once |
| The dashboard becomes slow | Queue size, repeated tasks, and database load | Queue drains without new failures or admin delay |
If the main complaint is dashboard delay, compare the queue with the wider checks in our slow WordPress admin diagnosis. Cron may be the cause, but it can also be one symptom of a larger database or plugin problem.
What a maintenance record should prove
A useful maintenance record should not say only that cron was “fixed.” It should show the failed layer, the evidence, the change, the test event, the next automatic run, and any remaining risk.
- Which business function was affected.
- Whether the trigger, queue, or task failed.
- How many meaningful events were overdue.
- What configuration or code changed.
- Which safe event proved the repair.
- Whether the next automatic interval also passed.
- What alert will catch the problem next time.
That evidence belongs beside backups, update checks, uptime, forms, and checkout results. It turns routine WordPress maintenance support into an accountable process instead of a list of completed buttons.
When maintenance is enough and when development is needed
Maintenance can usually repair a missing trigger, a stale hosting schedule, a small queue backlog, or a monitoring gap. Development becomes necessary when a custom plugin registers duplicate events, a callback cannot resume safely, a batch job needs locking, or the workload must be redesigned.
If you diagnose WordPress cron jobs not running on a business site, avoid clearing the full queue before you know what it contains. Preserve the evidence, test one path, and prove the next automatic run. Webless can help trace the scheduler from trigger to business outcome through a focused technical review.