Delivery & replay
Delivery, retries & auto-pause
A failed delivery (non-2xx response, timeout, or network error) retries with exponential backoff: 5s, 30s, 2m, 10m, 1h, 4h, then a final attempt at roughly 24 hours after the first. If an endpoint fails for 72 continuous hours, it's automatically paused and its creator is emailed — no further events are delivered until it's fixed and resumed.
Troubleshooting delivery issues
Common response outcomes and how to fix each one.
Can't connect | Make sure your host is publicly reachable and not blocked by a firewall. |
3xx redirect | Redirects are treated as failures. Point the endpoint at the final URL directly. |
4xx client error | Your server rejected the request. Check the URL is correct and doesn't require auth we don't send. |
5xx server error | Your server errored while handling the request. Check your application logs. |
Timeout | Your endpoint took too long. Return a 2xx immediately and process the event asynchronously. |
Event ordering isn't guaranteed
Events can arrive out of order, and retries mean the same event may be delivered more than once. Don't rely on delivery order, and dedupe by the envelope's id — never by created_at, since two events can share a timestamp.
Replay
Any individual delivery — successful or failed — can be replayed on demand from the delivery log in Settings → Developer → Webhooks. A replay re-enters the same delivery pipeline with a fresh retry cycle; it doesn't retroactively resend anything on its own.
Testing your endpoint
Use "Send test event" in Settings → Developer → Webhooks to fire a synthetic ping.sent event through the real delivery pipeline — signed the same way as every other event — so you can verify your endpoint before waiting for a real one to fire.