Retries and replays
Recover failed deliveries while keeping your event processing safe to repeat.
Acknowledge delivery
Return any 2xx status after securely and durably accepting the event. Requests time out after 10 seconds. Network failures, timeouts, and non-2xx responses count as failures; redirects are not followed.
Automatic retries
The default maximum is eight attempts, including the first. With the default multiplier of two, retry delays after failed attempts are:
| Retry | Delay after the previous attempt |
|---|---|
| 1 | 15 seconds |
| 2 | 30 seconds |
| 3 | 1 minute |
| 4 | 2 minutes |
| 5 | 4 minutes |
| 6 | 8 minutes |
| 7 | 16 minutes |
These are scheduled delays, not guaranteed arrival times. Endpoint configuration can change the attempt limit and multiplier; an individual delay is capped at one hour. A delivery is discarded after its final unsuccessful attempt.
An endpoint is automatically disabled after 20 consecutive failed deliveries. A delivery counts as failed only when it is discarded after its final attempt; failed attempts that will be retried do not count. A successful attempt resets that counter. Fix the receiver and resume the endpoint before expecting further delivery.
Replay a completed delivery
Open the webhook's delivery history in your dashboard and replay a delivered or discarded delivery. The endpoint must be active. A replay creates a new delivery call with the original event ID and payload; its attempt timestamp and signature are new.
Prevent duplicate work
Retries and replays can deliver an event more than once. After verifying the request, use the signed body's id as a durable idempotency key. Do not use the call ID for event deduplication: it changes on replay.
Do not assume events arrive in order. Separate accepting an event from slower work, as described in Webhook Ingester.