An order is sitting in WooCommerce, but the customer has no confirmation email. Or the customer received theirs while your team missed the new-order alert. Both can disrupt a sale, but they need different checks.
Start with one affected order. Establish which message was expected, whether its trigger happened, whether WooCommerce attempted it and what happened after it reached the mail system. Installing another email plugin before answering those questions can leave the original fault unresolved.
This guide covers standard WooCommerce order notifications. If an extension or external service replaces them, identify that route first and use its delivery records alongside the order.
1. Identify the missing message and its recipient
“Order emails are not working” is too broad to diagnose. Record the order number, approximate time, missing notification and intended recipient. Compare it with a recent order where that same notification arrived.
WooCommerce’s email settings guide distinguishes the shop’s New order notification from customer messages such as Processing order, Completed order and Order on-hold. A Completed order email follows the order being marked completed; it is not simply another name for the initial confirmation.
Ask these questions before changing anything:
- Is the customer missing a confirmation, or is the business missing its alert?
- Does it affect every order, one payment method or one notification type?
- Is the email absent, delayed, in junk or arriving at an old address?
- Did the problem begin after a website, hosting or email-service change?
Keep the investigation tied to the same order. A successful password-reset email or a different customer’s notification does not test the particular route that failed.
2. Check whether the order reached the expected state
Read the order notes and status before investigating the inbox. WooCommerce’s order-status documentation explains that Processing means payment has been received and fulfilment is outstanding, while Completed means fulfilment is finished. On hold can mean payment confirmation is still awaited. Orders containing only products that are both virtual and downloadable do not require the usual Processing stage.
Match the expected email to the actual transition. A customer waiting for a completion message while the order remains Processing may be seeing the intended workflow rather than an email failure.
WooCommerce’s email troubleshooting guide also identifies orders stuck at Pending payment despite successful payment as an order-update problem. Resolve that mismatch first. For the official Stripe extension, our guide to WooCommerce orders stuck on Pending payment after Stripe checkout explains the separate investigation.
Keep the order’s commercial state accurate. Moving an unfulfilled order to Completed merely to provoke an email obscures what the team still needs to do.
3. Check the individual notification settings
Go to WooCommerce > Settings > Emails and open the relevant notification. Confirm that it is enabled. For shop notifications, inspect the Recipient(s) field rather than assuming it still points at the person handling orders.
The email settings guide linked above documents comma-separated recipients for notifications sent to shop managers and administrators. Check spelling, old employee addresses and whether the intended shared inbox is actually listed. Check the customer address recorded on the affected order separately.
Also establish which component owns the message. An email customiser may change presentation, while another integration may replace the sending route. Give your developer the names of those components so they can trace the right code.
If the installed editor offers a test-email button, use it to check that template and destination. Then test a real order event in a controlled environment. A template test alone does not demonstrate that checkout triggers the expected notification.
4. Trace the email attempt in WooCommerce logs
You may already have useful diagnostics. The WooCommerce 10.9 release notes, published on 23 June 2026, confirm that transactional email logging shipped in core. Check your installed version before expecting this feature; 10.9 is the introduction point, not a recommendation to install that historical release.
On a version providing it, go to WooCommerce > Status > Logs, look for the source transactional-emails and match the order, email type and time. The current troubleshooting guide explains these outcomes:
| Outcome | What it establishes | Next check |
|---|---|---|
| Sent | The message was handed to the mail system. | Follow it into the sending service and recipient mailbox. |
| Failed | The mail-sending process returned an error. | Correlate the failure details with the sending service’s records. |
| Disabled | The notification was switched off. | Confirm whether that was intentional before enabling it. |
| Skipped | A required condition was missing, such as a recipient. | Repair the specific missing condition. |
If there is no matching entry
Missing evidence needs another check. WooCommerce’s technical explanation of email logging documents logging controls, retention and a filter that can disable logging globally or per email type. Successful attempts use INFO; disabled or skipped attempts use NOTICE. A restrictive logging threshold can therefore hide useful entries.
Check those controls and whether the relevant date is still retained before reproducing the issue. Logging enabled now cannot reconstruct an earlier missing record.
The technical guide also notes that disabled and skipped emails are absent from order notes. An empty notes section alone cannot establish what happened. It describes a rare case where another plugin’s near-simultaneous email failure can affect the captured error reason, so correlate that detail rather than treating it as conclusive.
If a fresh, expected notification still produces no entry after logging is verified, ask the developer to check errors, custom email handling and extension conflicts. Reproduce suspected conflicts on staging before changing the live shop.
5. If it says Sent, follow the delivery route
A successful handover is a useful boundary in the investigation. WordPress’s wp_mail() reference explicitly says that a successful return value does not prove the recipient received the email.
Ask whoever manages website email to locate the same message in the actual sending service’s records. Use its timestamp, destination and message identifier where available. Establish whether the service accepted it, rejected it or recorded a later delivery problem. Then check junk, quarantine and mailbox rules with the recipient.
Compare customer and staff notifications independently. A message reaching your business inbox does not establish that another destination accepted its own message.
WooCommerce’s sender authentication guidance recommends a From address on your business domain and authentication appropriate to the actual sending route. Have the email administrator check SPF, DKIM and DMARC for that route. Using a familiar address in the From field alone does not authenticate the website’s sender.
Preserve a clear before-and-after test when repairing the route. Changing hosting mail, a sending plugin and domain records together makes it harder to establish which change solved the fault.
6. Recover missed communication without repeating the order
Once the cause is understood, review the affected period. Separate customer confirmations from staff alerts, then decide which messages still need sending. A customer already speaking to your team may need a clear personal update rather than an unexplained old notification.
For each affected order, confirm payment, fulfilment and previous communication before a controlled resend. Use the supported action for the required message in your installed setup. Record what was sent and who handled it.
Keep recovery attached to the existing order. Creating another order or cycling statuses solely to generate notifications makes reconciliation harder. Check whether a delayed message is already queued before sending a replacement.
During the incident, have the team review the order list directly at agreed intervals so fulfilment does not depend entirely on an email alert. Tell customers what has happened when their confirmation or delivery update is affected.
7. Verify the complete notification journey
WooCommerce’s testing-orders guidance recommends staging and explains that test orders can trigger emails and connected integrations. Use controlled addresses and the payment method’s test facilities, with fulfilment integrations isolated from real dispatch.
Build the test around what actually failed:
- Place a test order through the affected checkout route and confirm its expected status.
- Match the customer notification and shop alert to their separate log entries.
- Trace each message through the configured sending route.
- Confirm receipt in the intended mailboxes, including a customer mailbox outside your business domain.
- Check the message content, reply destination and order links.
- Where relevant, complete fulfilment and verify the completion notification separately.
Record the order reference, expected messages, evidence and outcome. A green test-email button is not the acceptance criterion; the correct order event must produce the correct message for the correct recipient.
After deployment, monitor the next genuine orders through the live route. A staging repair still needs live verification because addresses, connections and mail handling can differ. Give someone responsibility for noticing future notification failures before customers have to chase.
If your shop takes orders reliably but its notifications are letting customers or staff down, BuzzBoost’s web development and integration work can help trace the handover. Contact BuzzBoost with the affected notification, order references and checks already completed.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
