Read the state before you resend
The response is the thing that must not be lost. The notification is an attempt, and it can be retried when the state says so.
The order
1. open the inbox and find the saved response
2. confirm it exists, with a timestamp
3. read the delivery row: queued, pending, accepted, failed, unknown
4. check the destination configuration
5. check the provider's status, where a provider is involved
6. retry only if the state says nothing left the server
7. tell the submitter what is true
8. check other submissions in the same window
A filled incident
Fifth of October 2026, Meridian Landscaping, one missed quote request.
14:02:11 visitor submits the quote form
14:02:12 response stored, receipt r_4c19
14:02:12 delivery row created, state queued
14:03:02 worker attempt, provider timeout, no status returned
14:03:02 delivery row state becomes unknown
14:40 the owner reports no email
steps and findings
1. inbox response present, full message readable
2. state unknown, one attempt
3. destination verified address, correct
4. provider partial outage reported from 13:50
5. decision do not retry. A retry could duplicate a late acceptance
6. action reply to the visitor from the stored response, 14:52
7. record incident logged 15:05 with the provider reference
8. window four submissions, four stored, one other unknown
15:20 provider recovers, both unknown rows settle as accepted
outcome
- nothing was lost: four submissions, four stored responses
- one delivery was late, not missing
- no retry was sent, and none was needed
Acceptance: the incident is closed when
- every submission in the window has a state
- each affected submitter has been told the truth
- a retry was sent only where the state allowed it
- the record names the time, the cause and the decision
- the fix is recorded, so the next incident is faster
Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| No response in the inbox | The endpoint never stored it | Check the endpoint and the origin rule |
| Stored, delivery unknown | A provider timeout | Reconcile, and never retry blind |
| Two notifications later | One send was accepted twice | Deduplicate by response id |
| The same address always fails | Bounce, or a blocked recipient | Verify the address, then change it |
| Nobody noticed for days | No daily read of delivery states | Add one, or alert on failures |
Limits
A retry can duplicate a notification, so a receiving webhook should deduplicate by the response id.
Never delete a response because its notification failed. The response is the part that cannot be recreated.