What matters first: WP-Cron is request-driven by default. Events can remain overdue when traffic is absent, loopbacks fail, DISABLE_WP_CRON is set, the cron lock is stuck or one callback repeatedly crashes.
What this symptom actually tells you
A queue of overdue events is evidence of a scheduling incident, but not every late event has the same cause. The event list, next run, callback and PHP logs reveal whether the scheduler never started or started and failed.
Capture evidence before changing anything
- List overdue events with their hooks, next-run times and recurrence.
- Check DISABLE_WP_CRON and any real server cron that should replace visitor triggering.
- Inspect loopback health and the cron lock transient.
- Run one affected hook manually while watching PHP and application logs.
Most common causes
- No trigger: Low traffic or disabled visitor cron leaves due events untouched.
- Broken replacement cron: The server cron command uses the wrong path, URL or PHP binary.
- Stuck lock: A crashed request leaves cron believing another process is still running.
- Failing callback: One plugin task times out, exhausts memory or throws a fatal error.
Safe diagnostic and repair sequence
- Choose either reliable visitor triggering or a real system cron, not an undocumented mixture.
- Run wp cron event run –due-now in a controlled window and capture failures.
- Repair or remove the specific callback that blocks or floods the queue.
- Monitor queue age and recurrence after the next normal scheduling cycles.
How to choose between the likely causes
Do not treat No trigger and Broken replacement cron as interchangeable. Low traffic or disabled visitor cron leaves due events untouched. By contrast, the server cron command uses the wrong path, URL or PHP binary. Use two checks to separate them: List overdue events with their hooks, next-run times and recurrence; and check DISABLE_WP_CRON and any real server cron that should replace visitor triggering. Those observations usually show whether the next safe move is to choose either reliable visitor triggering or a real system cron, not an undocumented mixture or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not run every overdue task repeatedly on a busy production store. Some jobs send emails, charge renewals or process orders and must remain idempotent.
How to verify the repair
- Overdue events fall to an expected baseline.
- New events execute close to their scheduled time.
- Critical jobs run once and leave auditable success or failure logs.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
A queue of overdue events is evidence of a scheduling incident, but not every late event has the same cause. The event list, next run, callback and PHP logs reveal whether the scheduler never started or started and failed.
- 1
List overdue events with their hooks, next-run times and recurrence.
- 2
Check DISABLE_WP_CRON and any real server cron that should replace visitor triggering.
- 3
Inspect loopback health and the cron lock transient.
- 4
Run one affected hook manually while watching PHP and application logs.
What must be verified
- Overdue events fall to an expected baseline.
- New events execute close to their scheduled time.
- Critical jobs run once and leave auditable success or failure logs.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Does a growing queue of overdue events always mean the scheduler crashed?+
Not necessarily. Overdue events can indicate the scheduler never triggered at all, or that it started but one callback keeps failing and blocking the queue. The event list, next-run times, and PHP logs distinguish a trigger problem from a callback problem.
I set up a real server cron — why are tasks still not running on time?+
A replacement system cron only works if it uses the correct path, URL, and PHP binary; a misconfigured command can silently fail to trigger anything. Confirm DISABLE_WP_CRON is set correctly and that the actual cron command executes without error before assuming the setup is complete.
Is it safe to force-run every overdue task at once on a live store?+
No. Some overdue jobs send emails, process renewals, or charge orders, and running them all repeatedly on a busy production store can duplicate those actions. Run affected hooks in a controlled window and confirm jobs are idempotent before batch-clearing a queue.
What is a 'stuck cron lock' and how is it different from a task that's genuinely still running?+
A stuck lock happens when a previous cron request crashed but left behind a transient that tells WordPress another process is still active, so new events are held back even though nothing is actually running. Inspecting the cron lock transient alongside loopback health helps confirm whether this is the case rather than a callback that is genuinely still executing.