Gravity Forms can log that a notification was generated and handed to WordPress while the SMTP layer never records a provider message ID. That evidence gap makes teams argue about whether the form, wp_mail, SMTP plugin, provider, suppression list, or recipient mailbox owns the failure. A time-bounded alert turns the missing join into an observable incident instead of a vague email complaint.
Use this for important lead, order, application, and support forms where notification delivery needs an auditable chain from Gravity Forms entry to the mail provider.
Quick answer
Create a correlation marker from entry ID, notification ID, recipient hash, and request ID. Record the Gravity Forms generation time and wp_mail handoff, then expect an SMTP or provider message ID within a short budget. Alert only when the handoff exists and the provider ID does not, and route the alert to the owner of the SMTP integration with sanitized evidence.
What to check first
- Enable Gravity Forms logging only for the affected component and reproduce one controlled entry.
- Capture entry ID, form ID, notification ID, request ID, recipient hash, wp_mail result, and all UTC timestamps.
- Find the SMTP plugin log or provider event that should contain the same correlation marker or Message-ID.
- Set a normal handoff budget based on observed provider latency instead of an arbitrary instant failure threshold.
- Check provider suppression, authentication, quota, API, and network errors before blaming the recipient mailbox.
Why this usually happens
- wp_mail returning true means the message was accepted for processing, not that an external provider accepted or delivered it.
- SMTP plugins and providers use different identifiers unless a deliberate correlation marker joins their records.
- Debug logs may rotate before support looks at the incident, leaving only the form entry and a user report.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
entry_id,notification_id,request_id,wp_mail_at,provider_id,age_s,state
8812,admin_notice,req-7f2,13:02:11,msg_92ab,4,accepted
8813,sales_notice,req-7f3,13:06:44,,38,alert
8814,user_notice,req-7f4,13:09:10,msg_a112,7,suppressed
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Add one sanitized correlation marker to the Gravity Forms and mail transport logs. | Enable Gravity Forms logging only for the affected component and reproduce one controlled entry. | Every controlled notification joins entry, notification, request, wp_mail, and provider identifiers. |
| Write provider IDs back to a durable delivery record. | Capture entry ID, form ID, notification ID, request ID, recipient hash, wp_mail result, and all UTC timestamps. | The alert fires for a missing provider handoff and stays quiet for normal delay. |
| Calculate the missing-ID age from the wp_mail handoff timestamp. | Find the SMTP plugin log or provider event that should contain the same correlation marker or Message-ID. | Provider rejection and recipient suppression appear as distinct states. |
| Send alerts to the SMTP integration owner with entry and request IDs. | Set a normal handoff budget based on observed provider latency instead of an arbitrary instant failure threshold. | Logs retain enough sanitized evidence for the support response window. |
Decision rule
Page the mail integration owner when a valid Gravity Forms notification has a successful WordPress handoff but no provider identifier after the measured normal budget. Do not label it an inbox failure until provider delivery evidence exists.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Normal send | Provider accepts inside 15 seconds | No alert and provider ID is joined |
| SMTP rejection | Provider returns an authentication error | Alert includes the rejection and integration owner |
| Lost callback | Provider accepts but local ID writer fails | Alert separates callback loss from send failure |
| Suppressed recipient | Provider accepts request then suppresses delivery | Provider ID remains present and suppression is a later state |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Add one sanitized correlation marker to the Gravity Forms and mail transport logs.
- Write provider IDs back to a durable delivery record.
- Calculate the missing-ID age from the wp_mail handoff timestamp.
- Send alerts to the SMTP integration owner with entry and request IDs.
- Retest generation, provider acceptance, suppression, and final inbox evidence separately.
Production verification checklist
- Every controlled notification joins entry, notification, request, wp_mail, and provider identifiers.
- The alert fires for a missing provider handoff and stays quiet for normal delay.
- Provider rejection and recipient suppression appear as distinct states.
- Logs retain enough sanitized evidence for the support response window.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not use a successful status or screen message as the only proof. Verify the business outcome and the underlying record.
- Do not leave debug logging, broad credentials, test orders, or temporary exceptions active after the review.
- Do not close the incident without recording the fixture, timestamps, owner, result, and rollback point.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, cache, data shape, and integrations. Finish with one controlled production fixture when the result depends on real routing, provider, or edge behavior.
What evidence should be retained?
Keep the smallest useful set: stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, version inventory, and the final verification.
When should the change be rolled back?
Roll back when a revenue, privacy, security, or publishing path fails and the cause cannot be isolated inside the approved maintenance window.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, trace a Gravity Forms delivery gap.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Keep Gravity Forms provider evidence long enough to investigate
Define the Gravity Forms notification provider-ID retention SLO for entry IDs, Message-IDs, provider events, evidence-ready timing, privacy-safe fields, deletion jobs, and severity-based ownership.
Helpful references