An empty Playground Email panel does not automatically mean your WordPress notification failed. First establish whether the message used the capture path, whether the current session was ready and whether the application triggered the message at all.
Know what this tool can prove
The official Email tool guide describes a browser capture of the normal sendmail path. SMTP and direct provider API integrations can bypass it. A captured message helps inspect generated content; it does not prove delivery to Gmail, Outlook or a customer's inbox.
Keep a disposable Playground separate from production credentials. If you import a site, review its mail and webhook integrations before triggering forms. Our staging email isolation guide explains why changing the visible site URL alone is not sufficient protection.
Start with one controlled action
Open Dev Tools, then Email, after the Playground has finished loading. Create one synthetic user or submit one test form using an address under example.invalid. Record the action time and a unique reference in a field that should appear in the notification.
Do not reload the Playground while inspecting the result. Captured messages belong to the current runtime session and are cleared when it is reloaded or reopened. A persisted site is not a persisted mail capture archive.
If nothing appears, check whether the workflow actually sends a notification in that state. A form can save an entry while conditional notification rules suppress the email. Compare the rule inputs, not merely the success message on the form.
Reference: One unique synthetic submission. Session: Inspect before reloading. Content: Correct recipient and fields. Delivery: Do not infer from capture. Explanatory checklist, not a customer test result.
Use a transport-versus-trigger worksheet
| Test |
Observation to record |
Next step |
| Known basic WordPress notification |
Captured or absent |
Establish that capture works in this session |
| Plugin action with expected notification |
Entry ID and notification condition |
Check trigger if only this action is absent |
| Same plugin using an external transport |
Transport configured |
Inspect the provider's controlled test environment |
| Message appears but content is wrong |
Recipient, subject and reference |
Trace the template and field mapping |
Keep the comparison narrow. Enabling several SMTP plugins at once makes the route harder to understand. Use the plugin's documented configuration on a disposable copy and record any difference from production.
Review the message before calling the test complete
Confirm the intended recipient, a recognizable subject and the submitted reference. Inspect both the plain text and HTML presentation when available. Check that customer-entered values are displayed as data and that an administrative notification does not accidentally include information meant only for the customer.
A duplicate message needs a separate investigation. Record each captured timestamp and compare the triggering actions before assuming delivery retries. One click may initiate multiple configured notifications, which can be legitimate if their recipients and purposes differ.
Move from capture to a real delivery test
After content passes, use a separate controlled staging delivery test with an authorized mailbox and the intended provider. Record provider acceptance and inbox receipt separately. Do not describe a successful Playground capture as proof that DNS authentication or production delivery is healthy.
For a form that saves leads but loses notifications, HandL WP can trace the trigger and transport. Supply the synthetic reference, relevant rule settings and redacted transport result, not mail credentials.
References reviewed October 16, 2026. Examples are explanatory, not customer test results.
If the reproduction also depends on Terminal commands, separate runner limitations from plugin failures: WordPress Playground Terminal: Unsupported Commands.