If scheduled posts, backups or maintenance tasks miss their times, first determine whether they never started or started and failed. One plugin’s blocked queue differs from a shared WP-Cron trigger problem.
Check the configured time, server-trigger arrangement and task output before replaying jobs or changing scheduling settings.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Evidence | Check | Meaning |
|---|---|---|
| One plugin task fails | Its queue and execution logs | The trigger may still work. |
| Several unrelated jobs are overdue | Shared trigger and loopback | WP-Cron may not be starting reliably. |
| DISABLE_WP_CRON is enabled | Replacement server schedule | It can be an intentional configuration. |
| Manual task works; scheduled task does not | Automatic trigger and timezone | Manual success does not verify scheduling. |
Compare the scheduled time with the actual result
Check the site’s timezone under Settings → General, then compare the task’s intended time with the current time shown in the relevant plugin or post settings. A timezone mismatch can look like a late scheduler when the job is actually waiting for its configured time.
For a post, verify its status and scheduled date. For a backup, look at the plugin’s history and whether an archive exists. Some jobs start successfully but fail while doing their work; others never begin. Those are different points of failure.
Keep a few examples rather than repeatedly creating new events. If scheduled posts, update checks, and several plugin tasks are all delayed, investigate the shared trigger. If only one plugin’s queue is stuck, examine its own logs and requirements.
Check how this site starts cron
Maintenance record: keep the site timezone, normal trigger method, replacement schedule if any, and its last successful run. Verify a replacement scheduler before relying on it. A configuration flag alone does not tell you whether due work runs.
Some hosts deliberately use a server scheduler instead of relying on page requests. In that setup, DISABLE_WP_CRON may be set to true in wp-config.php. That setting is not necessarily an error: it disables the usual trigger, while a separate scheduled job should run the work.
Ask the host or developer whether that replacement exists and when it last ran successfully. Removing the setting without understanding the arrangement can obscure the real problem. If no replacement exists, the site may have no reliable way to start its due tasks.
Cached visits may be served without reaching WordPress’s normal PHP processing. A busy-looking traffic report is therefore not proof that every visit starts a cron check. For time-sensitive work, a verified server trigger can be more predictable than depending on visitor activity.
Look for failed loopback requests
In the usual configuration, WordPress can attempt a request back to its own cron endpoint. Open Tools → Site Health and review loopback and scheduled-event warnings. A firewall challenge, password protection, DNS issue, or redirect problem can interrupt that request.
A staging site behind HTTP authentication may fail loopback checks for an expected reason. A production site needs its actual configuration reviewed. Give the host the warning, the time of the test, and any matching firewall event so it can distinguish blocked access from an application failure.
Do not assume that a working public homepage settles the question. The internal request takes a different path and may run as a different client. Our REST API guide and cURL timeout guide cover related communication symptoms.
Separate the queue from the job itself
- Inspect overdue events without deleting the queue.
- Determine whether the task began.
- Compare the start time with PHP and plugin logs.
- Test a harmless scheduled event before replaying tasks with external effects.
A cron inspection tool or a developer using WP-CLI can check which events are due and whether cron spawning works. Running an event manually can be useful, but first understand what it does. A task that sends messages, takes payments, or changes records should not be replayed casually.
If an event starts and then stops, review the PHP logs and the plugin’s own log at that time. A long backup or import can exhaust a limit even when cron triggered correctly. For a store, also inspect the scheduled-action queue used by the relevant extensions; it is not identical to the basic WP-Cron event list.
Repeated overdue events can create a backlog. Repair the trigger first, then let the responsible tool process its queue in controlled batches. Removing all scheduled events may hide the warning while breaking future work.
Verify the next scheduled run
After the repair, choose a harmless task with a known time and check its actual output. Then watch the next normal run of the affected backup or plugin job. A task that succeeds only when clicked manually still needs its automatic trigger checked.
Record the trigger arrangement and timezone so future changes do not accidentally disconnect them. WordPress documents WP-Cron scheduling and using a system scheduler; its WP-CLI cron commands provide additional checks for administrators.
Confirm the next automatic run
Verify the output of a harmless task at its intended time, then check the next affected plugin run. Record actual start and completion times. If a task only succeeds when started manually, continue investigating the automatic trigger.