A saved WooCommerce order proves checkout created a database record. It does not guarantee the order reached a status that triggers email, that the notification is enabled or that the message reached either mailbox.
Protect fulfilment first, then trace a test order by order ID and status history.
Triage real orders
Review orders created since the last known delivered notification. Authorised staff should verify payment and fulfilment from WooCommerce or the payment provider rather than waiting for email.
Do not resend every notification blindly; customers may receive duplicates and staff can fulfil twice. Record which orders need manual contact.
Use a test product, approved payment method and synthetic addresses for diagnosis.
Check the order status transition
WooCommerce emails are triggered by particular status changes. A card order may move to Processing or Completed, while bank transfer can remain On hold. A failed webhook may leave an order Pending payment.
Open the order notes and compare payment-provider status with WooCommerce. Confirm the expected transition occurred once.
Do not force an order to Completed merely to make an email send if payment or fulfilment is unresolved.
Inspect WooCommerce email settings
Under WooCommerce email settings, verify the relevant customer and administrator emails are enabled. Check recipients for new-order notifications, sender name/address and template status.
Custom code or an email customiser may alter recipients and triggers. Test the standard email path on staging before replacing templates.
Use an authenticated domain address in From and keep customer addresses out of From.
Distinguish customer and staff messages
New order, cancelled order and failed order emails normally target configured staff recipients. Processing, completed and invoice emails commonly target the billing customer based on order state.
Record exactly which notification is missing. A customer receipt arriving does not prove the administrator’s New order email was generated.
Check each recipient and trigger independently with the same test order.
Review scheduled actions and queues
Extensions can defer email or order processing through Action Scheduler. Inspect pending, failed and cancelled actions around the order time, including payment/webhook tasks.
Preserve action IDs and errors before retrying. A retry must not charge, fulfil or send twice; confirm the extension’s idempotency behaviour.
Check WP-Cron/server cron and hosting resource limits if the backlog grows.
Follow WordPress and SMTP evidence
Search the protected mail log by order reference, recipient and timestamp. If no message exists, stay with status, notification hooks and PHP errors.
If WordPress handed it off, find the message in the SMTP provider log and record acceptance, deferral, bounce or suppression. After acceptance, inspect recipient quarantine and rules.
Do not rely only on wp_mail() success.
Check template and extension errors
Outdated overridden WooCommerce templates, custom hooks and PDF invoice add-ons can throw an exception while building email. Review WooCommerce status reports and PHP logs.
Update overrides through a backed-up, tested path. Do not delete the custom template until required branding, tax and legal content is preserved.
Test with and without the optional attachment on staging to isolate it.
Check multilingual stores and tax/invoice extensions separately: they can select another template or delay the message until a document is generated.
Verify order and delivery outcomes
Place a new controlled order after repair. Confirm payment/status transition, correct staff and customer notifications, provider acceptance and final mailbox delivery.
Check totals, addresses, Reply-To and attachments without exposing payment data. Test the main payment methods because their status paths differ.
Request urgent WooCommerce email repair when paid orders may be unfulfilled or retries could duplicate actions. Share order IDs, statuses and redacted logs—never card data, passwords or customer contents.