Thousands of Scheduled Action in Pending mode can delay email, webhook, inventory sync, subscription, or maintenance tasks. But before you announce an incident, look at the execution time: the planned actions for the future are normal.
Urgent action:Do not truncate tables and run all the actions in one place. First, take a backup from the database, count overdue pendings based on the hook/group, and record the oldest time. Then check cron/runner, failures, PHP logs, and resources in the same space.
Do you really have a backlog?
- The number of pending with the past, not all future.
- The oldest action ready to run.
- New action rate to complete per minute
- Hook or group dominate
- Old failed and in-progress
- Start time for the problem with the update or the default.
To identify the components of the array, first,The action scheduler and the commerce guideSee. An integer without status and scheduled date can be misleading.
Prioritize the business effect
| The type of Hook. | Possible effects of delay | Priority of the review |
|---|---|---|
| Payment/Subscription | Financial situation or extension delayed. | The crisis, the reconciliation needed. |
| The entity/ERP | Stock or old price. | Up there. |
| Webhook/email | Integration or late notification | Depends on the consumer. |
| Cleanup. Reporting. | Growth or reporting late. | Usually lower. |
Batch execution must be consistent with business priorities. Clearance may take time but no extension validation. Args and logs can contain sensitive data; redact public output.
wp-cron or actual Cron is not running
If wp-cron is inactivated in the settings, the operating system should be replaced with the correct timing and URL/command. If it relies on site traffic, the low-traffic site or loopback fails to start the runner late. Check the last run time and cron log. Several parallel schedulers can also overlap and push.
Loopback and internal request
Internal DNS, HTTPS, Basic Auth, WAF, or language redirect may reject the loopback request. Site Health and access logs indicate. Do not disable TLS verification or remove the hostname; make DNS, certificate chain, and endpoint access. Having a 200 main page from within the server does not necessarily prove runner performance.
Fatal error on a hook
A faulty callback may slow down the batch or cause multiple failures. Match the WooCommerce log, PHP error log, and Action log with a timestamp. Stack trace should show the owner plugin.
Long Action or external API
Sync ERP, webhook, or API can hold the worker to timeout. Measure connect/read time, status, and retry. Increasing the timeout allows fewer actions to be completed in a time unit. Operations must have limited timeout, backoff, and idempotency; a blind retry may execute a financial or inventory request twice.
Production is higher than consumption.
Even without the error, if more action is created than the runner's capacity per minute, the line will grow. Draw the schedule and complete rates for the dominant hook. The cause can be large imports, special sales, large-scale sync, or defective producers.
Producer defects and similar actions.
If the same hook and args are repeated at very short intervals, check the schedule location. Each page load or retry may create a new action. First stop the producer or rate-limit; deleting the backlog while production continues gives a temporary result.
PHP-FPM and resource constraints
The runner has a user-requested worker and shared resources. See the PHP, CPU, available memory, I/O and MySQL connections in backlog time. Increasing worker without sufficient RAM can create an OOM or swap. If jobs are competing at the clock, redesign the timing and capacity share.
Lock, Claim and In-progress old
A process pause in mid-run can leave a claim or action running until the recovery mechanism releases its version. Direct manipulation of status and lock with SQL is at risk of running again simultaneously. Check the age, log and process status and use the supported API/server of the same version.
Database and Query line up
Large tables, inappropriate indexes, I/O or long transactions can slow down claims and updates. Check the slow log and execution plan on the clone. Optimize or index a limit on production may require a lot of lock and temporary space. First, specify backup and maintenance window capacity.
Copy and Migration are missing.
After the plugin update, the schema or callback may have changed. Check the module/plugin version, migration log and PHP/WooCommerce compatibility. Rollback files without a compatible database rollback can make the situation worse.
The phase-out program.
- Get backup and snapshot of the number/age of rows.
- Identify critical hooks and dominant producer.
- If the production is runaway, block the controlled source.
- Fix cron, runner, loopback and fatal errors.
- Slow down the API and remove the timeout/retry in the callback.
- Increase the capacity with a small batch and monitor.
- Constantly monitor the discharge rate, sources and side effects.
- After the evacuation, reconcile the backlog of business operations.
Control changes at incident time
When the backlog grows rapidly, temporarily stop unrelated deployment and change settings to keep the timeline interpretable. Record start time, last release, dominant hook, entry/exit rate, and exception sample in the incident log. If the customer order is affected, the support team should know which cases need to be reviewed.
After blocking the producer or eliminating the runner, see the backlog with a small batch of discharges and resources. If the rate of completion drops, stop the batch and check the bottleneck; the goal is not to quickly zero the number, but to recover without side effect and without deactivating the Checkout.
Why is Run All dangerous?
Running thousands of actions simultaneously can saturate PHP and the database, run external API rate-limit and run old operations in no order. Some actions are no longer valid after a business change.
Why isn't Delete All the solution?
Pending may be only records of payment transactions, emails, subscriptions, or inventory. Deleting them will zero the number but will leave the business status incomplete. Cancel or delete is only acceptable when the owner of the hook, effect, substitute, and reconcile list is clear.
What should we apply after recovery?
- Payment and order status with gate panel
- Extensions and customer access
- Availability and price with ERP
- Webhooks received by destination
- E-mails sent and the possibility of repeat.
- Reports and cleanups that are out of date.
Realistically estimate the time of the row's evacuation.
If you have 30,000 actions ready and the net capacity is 300 actions per minute after the new action breaks, the theoretical discharge takes about a hundred minutes; the hook time and rate limit can change this rate. Calculate the net rate regularly and identify the capacity transition with increased latency and error.
Increasing is also useful if the database, PHP and destination service are not saturated. The net rate drop is no longer associated with increased worker signal latency; first, remove the collar.
Preventive warnings
Warn of the oldest pending overdue age, failure rate, schedule to complete interval, and oldest in-progress number. Separate metrics by hook or group. Also display cron heartbeat, PHP queue, DB latency, and external API alongside it to avoid causing an error.
Common Mistakes
- Count future actions as backlog
- Truncate tables or change status with SQL
- Run All in the production
- Increased concurrency without measurement capacity
- Retry financial operations without idempotency
- Delete failures before the exception is registered.
- Disabled without stopping the producer.
When do you need special assistance?
If the backlog includes an existing payment, subscription, or sync, deleting or executing the blind can cause financial loss and duplicate data.Support for the WooCommerce storeIt can analyze input/output rates, hook, cron, log and resources and design phase-out with reconcile.
Common Questions
How much is Pending?
It has no fixed number; the overdue age, the entry/exit rate and the importance of the hook are determining.
Does the PHP worker increase the row?
Only if the worker is bottleneck and has capacity RAM/database, the API slows or remains fatal error.
Can I cancel the old actions?
Once the owner is identified, the business effect and the alternative route.
Why does the line grow again after the evacuation?
The producer, cron, or stable capacity have not been modified. Compare schedule and complete rates again.