WooCommerce core and extensions use Action Scheduler for background work. A backlog can delay email, webhooks, subscriptions and other order tasks even though checkout continues creating orders.
Preserve the queue and classify failed actions before running or deleting them in bulk.
Measure the backlog
Open WooCommerce scheduled actions and count Pending, Failed, In-progress and Past-due actions. Filter by hook, group and date to identify whether email-specific work or the entire scheduler is affected.
Record several action IDs, scheduled times and error messages. Do not include order contents or tokens in screenshots.
Compare the first failure time with updates, migrations and hosting incidents.
Check WP-Cron and the server runner
WordPress normally triggers WP-Cron through site traffic unless disabled. A production setup may use a real server cron instead.
Confirm DISABLE_WP_CRON matches the hosting design and that the external runner calls the supported endpoint or command on schedule. Review its last execution and exit status.
Do not enable both uncontrolled runners and create overlapping processing without understanding locks.
Inspect the first failed action
Later jobs may fail because an earlier dependency never completed. Read the hook name, arguments cautiously, attempt count and stack/error for the oldest representative failure.
Match it with PHP and WooCommerce logs. A fatal error in an email customiser, subscription add-on or payment extension can stop that action while unrelated jobs continue.
Fix the specific dependency before retrying the queue.
Review hosting resource limits
Background batches need PHP memory, execution time, database access and available worker capacity. Check cPanel/Plesk CPU, memory, I/O, processes and disk at failure times.
Large backlogs can make every cron request exceed limits. Reduce batch pressure using supported configuration and improve the underlying resource issue.
Do not set unlimited execution or memory as a permanent workaround.
Check loopback and cron blocking
WordPress loopback requests can fail because of basic authentication, maintenance mode, DNS mismatch or a security rule. Review Site Health and the cron runner’s HTTP status.
Do not allow all loopback traffic blindly. Permit only the documented self-request path or use a controlled server cron that records its result.
Check database health and locks
Action Scheduler stores claims and logs in the database. Slow queries, crashed tables or long locks can leave actions stuck In-progress.
Use WooCommerce tools and database diagnostics appropriate to the installed version. Back up before repair and do not manually delete scheduler rows without understanding relationships.
Remove completed history only through supported cleanup after the incident.
Separate SMTP throttling
The scheduler may run correctly while the mail provider defers messages due to rate or account limits. Search provider events for the same period and record response codes.
Release transactional email at a controlled rate after fixing the limit. A sudden replay of hundreds of messages can trigger another block and confuse customers with stale notifications.
Reconcile which orders already received mail before retrying.
Retry safely
Determine whether the action is idempotent. Email may duplicate; payment capture, subscription renewal or fulfilment can have greater consequences.
Test one synthetic or low-risk failed action after the fix and verify its side effects. Then process a limited batch while monitoring logs and queue growth.
Never bulk-run unknown actions solely to make the pending count disappear.
Verify continuous processing
After recovery, confirm new actions run near their scheduled time, the backlog declines and provider delivery succeeds. Place a controlled order and trace status, staff/customer emails and final mailboxes.
Monitor scheduler health, PHP errors and mail rates over the next cycle. Add alerts for past-due action thresholds.
Request urgent repair when payment/subscription hooks are mixed with email or database claims remain stuck. Share hook names, counts and redacted errors—never order data, tokens or credentials.