A stuck WooCommerce email queue is not always an SMTP problem. The email may be waiting in Action Scheduler, blocked by WP-Cron, failing on template rendering, suppressed by order status, or rejected after handoff to SMTP.
Use this when customers do not receive processing, completed, refund, failed order, account, or reset-password emails from a WooCommerce store.
Quick answer
WooCommerce Action Scheduler Email Queue Stuck should be handled with a narrow evidence-first workflow: pick one order, review email log, check scheduled actions, then verify the result before making broader changes.
What to check first
- Check WooCommerce email logging and note whether the email was generated, queued, sent, failed, or missing.
- Review Action Scheduler pending, failed, and past-due actions for email, order, and webhook hooks.
- Confirm WP-Cron runs reliably and is not blocked by hosting, maintenance mode, or a security rule.
- Compare SMTP provider logs against WooCommerce logs for the same recipient and timestamp.
- Test the affected order status transition instead of sending only a generic test email.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Pick one order | Check WooCommerce email logging and note whether the email was generated, queued, sent, failed, or missing. | The affected order status transition creates the expected email. |
| Review email log | Review Action Scheduler pending, failed, and past-due actions for email, order, and webhook hooks. | Action Scheduler has no growing backlog of past-due email actions. |
| Check scheduled actions | Confirm WP-Cron runs reliably and is not blocked by hosting, maintenance mode, or a security rule. | SMTP logs show accepted delivery for the tested recipient. |
| Test WP-Cron | Compare SMTP provider logs against WooCommerce logs for the same recipient and timestamp. | The store owner knows whether the issue was WooCommerce, cron, template, or SMTP. |
Why this usually happens
- A payment or fulfillment plugin can schedule follow-up actions that never run.
- WP-Cron may only run on traffic, so low-traffic stores can build delayed email queues.
- SMTP can accept a message while the provider later suppresses or rejects the recipient.
- Action Scheduler 4.0 changes make cleanup and uniqueness behavior worth retesting before WooCommerce 11.0.
Field notes
- Start with one missing email and one real order ID. Broad email tests hide the failure point.
- If emails are logged as sent but not delivered, move to SMTP, DNS, suppression, and mailbox evidence.
- If emails are not logged at all, focus on order status, template errors, hooks, and queue execution.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp action-scheduler list --status=pending --per-page=20
wp action-scheduler list --status=failed --per-page=20
wp cron event list | grep -E 'action_scheduler|woocommerce'
wp option get cron | head
# Match one order ID across WooCommerce email log, Action Scheduler, and SMTP provider logs.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Pick one order
- Review email log
- Check scheduled actions
- Test WP-Cron
- Compare SMTP logs
What to tell the client or owner
Give the owner the tested order ID, the email type, the queue state, the SMTP result, and the next monitoring window.
Production verification checklist
- The affected order status transition creates the expected email.
- Action Scheduler has no growing backlog of past-due email actions.
- SMTP logs show accepted delivery for the tested recipient.
- The store owner knows whether the issue was WooCommerce, cron, template, or SMTP.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, fix WooCommerce checkout and order flow.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Alert on the oldest business-critical action
Build the WooCommerce Action Scheduler oldest overdue action dashboard so renewals, emails, webhooks, and imports page the right owner before queue size becomes misleading.
Measure latency by business-critical hook
Build the Action Scheduler per-hook latency SLO dashboard to separate overdue renewal, email, and webhook work from harmless future queue volume.
Find groups starved behind a noisy hook
Use the Action Scheduler group starvation detector when total throughput looks healthy but a small renewal, email, webhook, or import group exceeds its business deadline.
Helpful references
Test scheduled customer review requests
Stores using WooCommerce review request emails should also run the review request cancellation audit to prove refunded, cancelled, and trashed orders do not leave stale email actions behind.