WordPress
WordPress cron troubleshooting: why scheduled events run late or not at all
WordPress cron is request-triggered scheduling by default, not a traditional always-running system scheduler. Missed or delayed events can result from low traffic, disabled wp-cron, loopback/request failures, long-running callbacks, queue backlogs, or plugins that schedule more work than the hosting account can process.
Inspect scheduled events and lateness
Use WP-CLI or a trusted cron inspection tool to list hooks, next-run timestamps, recurrence, and overdue events. Identify which plugin owns a hook before deleting anything.
A large repeated queue may come from one failing callback; the scheduler itself can still be healthy.
Check how cron is triggered
If DISABLE_WP_CRON is set, confirm a real system cron or platform scheduler calls wp-cron or WP-CLI on the intended interval. If default request-triggered cron is used, low-traffic sites may naturally run tasks late.
Loopback restrictions, DNS, TLS, or authentication can prevent self-requests.
Find long or failing jobs
Review PHP errors, plugin logs, database locks, external API failures, memory/timeouts, and execution duration for the specific hook. Long jobs can overlap if the plugin lacks proper locking.
WooCommerce Action Scheduler is a separate queue worth inspecting when WooCommerce extensions are involved.
Move to controlled scheduling when needed
For predictable production scheduling, disable request-triggered cron only after a system scheduler is proven. Run jobs frequently enough for the application but avoid triggering overlapping copies.
- List overdue hooks.
- Verify the trigger mechanism.
- Trace the owning plugin/job.
- Prevent overlapping long runs.