What matters first: Action Scheduler is a job queue used by WooCommerce and many extensions for webhooks, subscriptions, emails, stock updates and background processing. Thousands of overdue actions are a symptom, not a diagnosis: the queue may be starved of runners, blocked by one failing hook or growing faster than it can be processed.
Measure the backlog before clearing anything
Count pending, failed and in-progress actions by hook and group. Record the oldest scheduled time and the rate at which new actions appear. That separates a stable historical backlog from an incident that is still accelerating.
Evidence that identifies the bottleneck
- Oldest pending actions and their hook names.
- Failure messages and retry history for the dominant groups.
- How often WP-Cron or another Action Scheduler runner actually executes.
- Database size, claim locks, PHP timeouts and memory during a controlled batch.
Four different causes need four different fixes
- Runner starvation: WP-Cron or the server runner rarely starts.
- Failing callback: one integration repeatedly throws an exception or times out.
- Producer flood: a plugin schedules actions faster than workers can consume them.
- Database pressure: large action tables or slow queries make every batch increasingly expensive.
Recover the queue without triggering a second incident
- Pause or limit the producer if the queue is still growing.
- Fix the dominant failing hook before increasing worker throughput.
- Process overdue actions in bounded batches while watching CPU, database load and business side effects.
- Only after recovery, clean completed or failed history according to the retention you actually need.
Runner problem or application problem?
If almost no jobs start, inspect WP-Cron and missed-schedule failures. If jobs run but one family repeatedly returns authentication errors, compare it with WooCommerce webhook 401/403 diagnostics. Increasing concurrency before making that distinction can simply make the failure faster.
Do not run the entire overdue queue at once
A mass run can send old emails, repeat external calls, trigger subscription work or overload the database. Decide which action groups are safe to replay and which require reconciliation first.
How to verify the recovery
The queue is healthy when its age and size return to a stable baseline, critical hooks complete once without repeated failures, new work is consumed at least as quickly as it is created, and WordPress, PHP and the database remain stable under normal throughput.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Queue size alone does not reveal whether tasks are slow, failing, blocked by WP-Cron or being produced faster than they run.
- 1
Count pending, failed and in-progress actions by hook and group.
- 2
Inspect the oldest actions, attempt logs and callback errors.
- 3
Check WP-Cron trigger health and runner frequency.
- 4
Measure database size, claim locks and PHP resources during processing.
What must be verified
- Queue age and size return to a stable baseline.
- Critical hooks complete once without repeated failures.
- WP-Cron, database and PHP remain healthy during normal throughput.
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.
Is it safe to run all the overdue actions at once to clear the backlog quickly?+
No. Overdue actions can include sending customer emails, charging payments, or writing large amounts of data, so processing them all at once on production risks duplicate charges, spam messages, or a database overload.
Does a large queue always mean the site is under heavy load?+
Not necessarily. A large backlog can mean WP-Cron itself is broken and the runner rarely starts, one specific integration is failing repeatedly and clogging the queue, or a plugin is producing actions faster than they can be processed — each needs a different fix.
Should I increase the Action Scheduler processing rate before finding the failing hook?+
No. The guide recommends repairing the dominant failed hook first, before increasing throughput, because raising processing speed on a queue with a broken callback just repeats the same failure faster.
Is it safe to delete old completed and failed actions to shrink the database?+
Only after recovery, and according to retention needs. Cleaning history is a valid step but should happen after the backlog's root cause is fixed, not as a substitute for diagnosing why actions piled up.