WooCommerce abandoned cart emails not sending? Follow the message.
A missing email can mean the cart was never captured, the message was intentionally skipped, the queue stopped, or the provider did not deliver. Find the last confirmed stage before changing settings or retrying a send.
Start with one checkout you control
- Use a staging store and your own inbox. Add a supported in-stock product, enter the email and select the recovery opt-in.
- Leave without paying and look for the captured cart in WooCommerce → WakeMyCart → Overview. Record its time and reference without copying shopper data into public support messages.
- Open Recovery health and Email sequence. Confirm capture and sending are enabled separately and the first reminder is actually due.
- Follow the table below. Fix one failed stage, then repeat the same controlled journey.
Match the symptom to the next check
| What you observe | Likely place to check | What to do next |
|---|---|---|
| No captured checkout | Capture switch, opt-in or checkout compatibility | Confirm consent saved; check browser/network errors on the checkout and the supported product profile. |
| Cart captured, no email due | Delay, purchase state, suppression or flow rules | Read the eligibility reason. A purchase or unsubscribe should stop sending. |
| Due messages stay queued | WordPress cron / Action Scheduler | Check Recovery health and WooCommerce Scheduled Actions; ask the host to verify the scheduler. |
| Pro licence or legacy usage warning | Store registration, signed allocation or legacy plan limit | For connected Pro, refresh the account and review usage. Free works locally without an account or contact quota; preserve local history. |
| Sender setup just changed | Provider revision and recovery pause | Save, verify and test the new sender, then explicitly enable recovery again. |
| Provider rejected a send | Credentials, verified domain, quota or recipient rejection | Read the provider’s error and fix that cause before retrying. |
| Accepted, but nothing in the inbox | Delivery or inbox placement | Inspect provider events, spam and recipient filtering. WordPress mail handoff alone does not confirm delivery. |
| Uncertain send outcome | Request may have reached the provider | Check the provider’s logs and follow the review action. Do not blindly resend and risk duplicates. |
On a quiet store, check the scheduler first
WP-Cron normally starts work when WordPress receives a request. A low-traffic store can therefore miss the intended sending time. Ask your host to set a reliable system scheduler and verify that due WordPress tasks run.
WakeMyCart’s guide recommends a one-minute invocation for recovery work. Do not disable WordPress’s default trigger until its replacement is configured and tested. Scheduled Actions should show recent execution, not just a growing list of pending jobs.
Separate handoff, delivery and inbox placement
A successful wp_mail call means the sending method accepted the request; it does not establish that the recipient received it. Use your SMTP provider’s delivery logs to investigate the next stage.
With your own Resend account, verify the exact sending domain and configure the signed webhook described in setup. A delivered event means the receiving server accepted the message. It still does not prove placement in the inbox or that a person read it.
Confirm the fix through a complete journey
- Receive a test email in your own inbox and check sender identity, layout and links.
- For an eligible test cart, receive the actual reminder and restore the cart from its unique button.
- Finish a test order and confirm later reminders stop. Separately test unsubscribe on another test cart.
- If it still fails, collect the redacted support summary, the affected stage and timestamp. Keep API keys, connection codes and recovery links private.