A private WooCommerce order note is not the same as a note sent to the customer. Before troubleshooting email delivery, open the exact order and confirm the note type. If it was customer-facing, trace that notification and its recipient separately from new-order and completed-order emails.
Check the note before the mail server
WooCommerce's order notes documentation distinguishes internal notes from customer notes. Use the text label and action chosen, not only the note's color, because administration styling can vary.
Check who added the note and when. A payment gateway's system note is not automatically a customer message. Do not convert an internal note into a public one without reviewing its contents; it may contain transaction diagnostics, staff comments or information the customer should not receive.
Reproduce with a harmless customer note
Choose a staff-controlled test order with a verified test mailbox. Add one plain customer-facing note with an identifying phrase. Do not use a real customer's order for a series of repeated delivery experiments.
Record the order ID, note timestamp, expected destination and selected email type. In WooCommerce's email settings, inspect the Customer note notification and any extension that changes its recipients or template. A successful completed-order email does not prove this separate notification is configured correctly.
Note: Customer-facing content reviewed. Destination: Correct order email saved. Handoff: Provider result identified. Inbox: One intended message received. Explanatory checklist, not a customer test result.
Locate the failed handoff
| What you observe |
What to investigate next |
| Only a private note exists |
The note was not a customer-notification test |
| Customer note exists, no email attempt |
Notification configuration, hooks or template failure |
| Provider rejected the attempt |
Sanitized sender, recipient or transport error |
| Provider accepted it, mailbox is empty |
Delivery events, quarantine and mailbox filtering |
Use the order email troubleshooting guide if several transactional messages fail. For this narrower issue, keep the note event distinct from an order-status transition. Changing a paid order's status merely to force an email can trigger other business actions.
WordPress's wp_mail documentation explains that a successful application return does not prove receipt. Match the application timestamp to the provider message ID and the controlled inbox result.
Correct the destination before sending again
Confirm the order's current billing email with the authorized customer or test owner. Do not assume the account profile and an older order contain the same address. If an address was corrected, save the order and reopen it to confirm the intended value persisted.
If the note contains a link, check the destination and access requirements before resending it. A delivered notification with a broken customer portal link is not a completed repair. Avoid putting private order links or full message bodies into shared logs.
Close the incident without creating duplicates
After the cause is fixed, send only the intended customer communication once, using the store's approved workflow. Keep a note of which message was sent and when so another team member does not repeat it.
HandL WP can trace the customer-note event when the note exists but the mail evidence stops midstream. Useful evidence is the redacted order reference, notification type and provider disposition, not shared payment details or administrator credentials.
References reviewed October 7, 2026. Examples are explanatory, not customer test results.