When a WooCommerce order email does not arrive, the missing message is only the visible symptom. The underlying cause may be a disabled notification, a skipped email condition, an error in the mail-sending process, or a delivery problem that occurred after WooCommerce handed the message to the site’s mail system. That makes WooCommerce email troubleshooting easier when you first establish what WooCommerce actually attempted.
WooCommerce 10.9.0 added transactional email logging to the core plugin. Store owners can therefore begin investigating from the WordPress admin area without installing a separate logging plugin first. The built-in record can show the relevant email type, the outcome, and, for failures, an available local error reported by WordPress, PHPMailer, hosting, or SMTP processing. It can also provide useful order-specific context through private order notes.
There is an important boundary: a sent status confirms handoff to the site’s mail system, not acceptance by the recipient’s provider or delivery to the inbox. This guide explains where to find the logs, how to interpret each status, how to investigate failed order emails, and when the next step belongs in your mail or hosting systems.
What WooCommerce 10.9 Adds for Email Troubleshooting
WooCommerce 10.9.0 introduced transactional email logging in the core plugin. The relevant records are available from WooCommerce > Status > Logs, giving store owners and support teams a central place to review WooCommerce transactional email attempts. This is useful as a first diagnostic step because it does not require a separate logging plugin before you can determine whether WooCommerce tried to send a message.
The feature records the result of the WooCommerce email process. A failed entry may include the reason returned by WordPress, PHPMailer, or the SMTP process, such as a connection or authentication error. A sent entry shows that the message was handed to the site’s mail system successfully. It does not prove that the recipient’s provider accepted the message, that it reached the inbox, or that it avoided spam filtering.
What the log covers—and what it does not
The relevant source is focused on WooCommerce transactional emails, such as order-related notifications. WordPress password-reset messages, general administrator emails, and other non-WooCommerce messages may not appear in the transactional-emails source. A missing record should therefore be considered in the context of the type of message being investigated.
Core logging also does not replace mail-service evidence for delivery investigations. If WooCommerce reports a successful handoff but the recipient does not receive the message, continue with the relevant SMTP-provider or hosting logs, sender-domain configuration, email authentication, and spam checks. The built-in log explains the WooCommerce side of the process; it is not a delivery guarantee.
Where to Find the transactional-emails Log
Start with a controlled reproduction of the problem. Trigger the relevant email with a test order or with the specific WooCommerce event that should generate the notification. Record the order context and approximate time, then open the WordPress admin area and go to WooCommerce > Status > Logs. Open or filter the source named transactional-emails.
Review the newest relevant entry and match its email type and order context to the test. This is more reliable than looking through unrelated records or assuming that a customer’s report identifies the exact failed event. For an order-specific investigation, compare the central log with the order’s private notes as well. The log is the primary place for all four outcomes, while order notes contain only selected order-related attempts.
Why an expected event may not appear
Visibility follows the existing WooCommerce logger configuration. Storage may use the configured file or database handler, retention rules determine how long records remain available, and the minimum log-level threshold affects which events are displayed. Consequently, logging can be enabled while some older or lower-level entries are no longer visible.
Successful, disabled, and skipped events can be hidden when the configured threshold excludes INFO or NOTICE entries. Failed entries are logged at WARNING, but the broader logging configuration still determines whether records are stored and retained. Check these settings before treating an absent entry as proof that WooCommerce did not make an email decision. Reproduce the issue first, and keep a record of the original configuration before changing production email settings.
How to Read Sent, Failed, Disabled, and Skipped Statuses
The four outcomes describe different points in the WooCommerce email workflow. Reading the status correctly prevents store owners from applying an SMTP remedy to a disabled notification or treating a missing recipient as a server failure.
| Status | Meaning | Next investigation |
|---|---|---|
| Sent | WooCommerce handed the email to the site’s mail system successfully. | For non-delivery, check mail-service, sender-domain, authentication, and spam evidence. |
| Failed | The mail-sending process returned an error after WooCommerce attempted the send. | Read the available WordPress, PHPMailer, hosting, or SMTP details. |
| Disabled | The relevant WooCommerce email notification is turned off. | Review the notification setting. |
| Skipped | A required condition, such as a recipient, was missing, so WooCommerce did not attempt the send. | Check the condition identified by the event. |
For order-related emails, sent and failed attempts are also added as private order notes. Disabled and skipped outcomes remain in the transactional-emails log but are not added to order notes. This distinction matters when a support team checks an order and finds no note: the absence does not rule out a disabled or skipped decision.
A quick status-based decision path
Use the status as the first branch in the investigation. With failed, inspect the available error details. With disabled, review the corresponding WooCommerce notification. With skipped, check the required condition named by the event, such as the recipient. With sent, move beyond WooCommerce generation and handoff if the message is not received.
This approach keeps the investigation evidence-based. It also avoids treating a sent record as confirmation of inbox delivery or treating order notes as a complete history of every transactional email decision.
Diagnosing Failed Order Emails
For a failed order email, locate the transactional-emails entry that matches the order and notification type. Confirm the status first, then read the available failure reason. WooCommerce may expose a local WordPress, PHPMailer, hosting, or SMTP error. Connection and authentication messages are clues that should be verified in the relevant mail, hosting, or SMTP configuration rather than treated as proof that one specific setting is responsible.
Next, compare the central log with the order’s private notes. Sent and failed order-related attempts can appear there, which gives freelancers, agencies, and support teams a convenient order-level view. However, the log remains important because disabled and skipped events are not copied into order notes.
Separating send failure from delivery failure
A failed status means that WooCommerce attempted the send and the mail-sending process returned an error. A sent status means that WooCommerce handed the message to the site’s mail system. If the status is sent but the recipient reports no message, the problem has moved beyond the WooCommerce handoff. Review SMTP-provider logs, hosting records, sender-domain configuration, email authentication, and spam filtering. Conflict testing or a dedicated mail logging tool may also be needed when the available evidence is insufficient.
The human-readable failure reason has a documented narrow limitation. Because wp_mail_failed is a global WordPress hook, a rare near-simultaneous failure can cause the displayed reason to be attributed to a different failure. The status and email type remain reliable, but the message should not always be treated as infallible in that unusual timing scenario.
WooCommerce Order Notes as a Support Shortcut
Private order notes provide a useful shortcut when the investigation concerns one order. Check the order’s notes alongside the matching transactional-emails entry to confirm whether an order-related email was recorded as sent or failed. This can help a support team connect the customer’s report with a particular notification attempt without searching the entire log history.
Order notes are supplementary evidence, not a complete transactional email history. WooCommerce adds sent and failed order-related attempts to them, but disabled and skipped events remain only in the transactional email log. If no note exists, check the central source before concluding that no email decision was recorded. When sharing notes or screenshots, remove customer information and retain only the context needed for troubleshooting.
Privacy, Retention, and Log Visibility
WooCommerce does not write raw customer email addresses to transactional email logs. A known recipient is represented by the matching WordPress username, while an address without a matching account is represented by a guest label. Multiple recipients are represented with labels rather than the raw addresses. This explains why the log may not display the full address that a store owner expects to see.
Email addresses that appear inside a PHPMailer or SMTP failure message are redacted. That protection reduces exposure, but it does not make exported or shared diagnostic data automatically safe. Administrators should still inspect screenshots, copied entries, support tickets, and browser demonstrations before sharing them. Do not publish customer addresses while documenting a failed WooCommerce email.
Safe handling of troubleshooting evidence
Share the status, email type, order context, and sanitized error detail instead of unredacted diagnostic data. Review the configured storage handler and retention behavior when deciding how long records should remain available. Also keep the original plugin, theme, SMTP, and production email settings documented before making changes, so a later comparison is possible.
Log visibility is part of privacy and troubleshooting context. Retention may remove older records, and a minimum log-level threshold can hide successful, disabled, or skipped events even when logging is active. A missing low-level entry is therefore not necessarily evidence that no event occurred.
When Core Logging Is Not Enough
The transactional-emails source is designed for WooCommerce transactional email attempts. It is not a universal record of WordPress mail, and it cannot confirm acceptance by a recipient’s provider, inbox delivery, or the absence of spam filtering. These limits are especially important when the log shows sent but the recipient sees nothing.
At that point, continue with the relevant SMTP-provider or hosting logs and check sender-domain configuration, email authentication, and spam filtering. A separate mail logging tool may be appropriate for delivery investigations or messages outside the WooCommerce transactional scope. Use controlled tests and conflict testing when the existing evidence does not identify the cause. Do not assume that changing one WooCommerce setting guarantees delivery.
For broader website tooling, you can explore WooCommerce plugins or browse WordPress plugins according to the store’s wider needs. Keep any product choice separate from the evidence shown by the email log, and do not assume that a listed product provides a particular logging, SMTP, compatibility, support, or delivery feature unless that capability has been separately verified.
The practical workflow is straightforward: reproduce the issue with a controlled test, open WooCommerce > Status > Logs, filter transactional-emails, and match the entry to the order and email type. Interpret the status before changing configuration. Failed points to an error returned by the sending process; disabled and skipped identify different WooCommerce decisions; sent confirms handoff, not delivery. Use private order notes as supporting evidence for sent and failed order emails, while remembering that disabled and skipped events are not added there. If records are missing, check storage, retention, and log-level settings. If a message is sent but not received, continue in the relevant mail and hosting systems. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.