# 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](/docs/webhooks/ingester).

---

Source: https://connect.nxiom.com/docs/webhooks/retries-and-replays