Troubleshoot webhook deliveries
Diagnose failed calls, recover an endpoint and replay missed notifications.
A failed webhook call means your server didn't acknowledge the notification. Check Activity for the email's actual delivery outcome.
Find the failed call
- Open Webhooks and click the endpoint.
- In Delivery log, select Failed and a time range: last hour, 24 hours, 7 days or 30 days.
- Click a call to open Webhook call.
- Review Result, Timing, Your server's response and Events in this call.
Copy Request ID and search your server logs for the webhook-id header. Each retry is a new request; use event id to correlate or deduplicate the same event across calls.
| Detail | How it helps |
|---|---|
| Sent as | Distinguishes Normal, Retry, Replay, Test and Skipped calls. |
| Timing | Splits DNS lookup, connection, TLS and waiting for your server's response. Reused connections can omit setup stages. |
| Event delay | Shows elapsed time from the event happening to the request being sent, when available. |
| Response | Shows a snippet of your server's reply, not necessarily its complete body. |
| Event IDs | Identifies notifications in the batch. Use Show all event IDs when the list is truncated. |
Resolve the result
| Result | What to check |
|---|---|
| 2xx | The call was acknowledged. If your app didn't update, investigate parsing, queueing and processing in your app. |
| 3xx | Redirects aren't followed. Set the endpoint URL to its final HTTPS address. |
| 401 / 403 | Check the configured auth-header name and value, firewall rules and endpoint access policy. |
| 404 / 405 | Confirm the route exists and accepts POST requests. |
| 429 / 5xx | Review rate limits, availability and application errors. |
| Timeout | Return a response within 10 seconds; connection setup has a 5-second limit. Move slow work to a queue. |
| No connection | Check DNS, public reachability, listening port and firewall rules. |
| TLS error | Check HTTPS, certificate validity and the certificate chain. |
| Blocked | The URL resolves to a private or internal address. Use a publicly reachable endpoint. |
A successful response can be any 2xx; its body is ignored. Accept the event durably before acknowledging it, then do slow processing asynchronously. A 2xx followed by an internal app failure won't trigger an automatic retry from SendMero.
Learn more about request handling →
If there are no calls
Check that the endpoint is Active, its event subscription includes the event, and its domain filter includes the sending domain. New endpoints don't automatically receive events from before their creation.
Widen the log's time range and use Refresh. Send a test to check connectivity, but remember that a test doesn't establish a real email event or validate every subscription choice. If the event hasn't happened yet, there is no notification to deliver.
Recover a paused or disabled endpoint
Repeated failures can pause normal delivery. While paused, SendMero tries a probe periodically; the first success resumes waiting deliveries. The dashboard describes the next probe and the recovery state. Continued failures for 24 hours disable the endpoint.
Fix the receiving service, send a successful test, then use Enable if disabled. Automatic catch-up covers events within the last 24 hours. Check for older gaps rather than assuming the entire outage was recovered.
Replay notifications
Replay resends webhook events; it does not resend emails. Fix the handler and ensure it ignores duplicate event IDs first.
Replay one call
- Open the call in Delivery log.
- Click Replay.
- Wait for the queued replay and refresh the log to check its result.
Calls must be within the last 7 days. Even a previously successful call can be replayed, so downstream actions must handle duplicates.
Replay failed calls in a period
- Click Replay failed… in Delivery log.
- Select Period, or choose a custom From and To within the last 7 days.
- Click Replay, then check the new calls.
Events already acknowledged by a successful retry are skipped by failed-range replay. Duplicates can still occur; don't use replay as a substitute for deduplication.
Ordinary failures are retried automatically according to the retry schedule. See Failures and retries. Replay controls require the appropriate workspace permission.
Escalate an unresolved issue
Share the endpoint URL, request ID, event IDs, time and time zone, result, and relevant server logs with support. Include whether the call was Normal, Retry, Test or Replay. Keep auth-header secrets out of screenshots and logs you share.
- Deduplicate by event ID, not request ID, and allow for events arriving out of order.
- Monitor lag and failure trends in Graphs as well as individual calls.
- Verify replay results instead of assuming that queued means successfully delivered.