# Delivery, retries and replays

> How Nexafon retries failed webhook deliveries for three days, turns off failing endpoints, and lets you see every attempt and replay events.

Source: https://docs.nexafone.so/v1/webhooks/retries/

## Retries

A delivery fails when your endpoint does not answer `2xx` within 10 seconds. Nexafon then retries with exponential
backoff: about 30 seconds after the first failure, then doubling (1, 2, 4 minutes…) up to one attempt every 12 hours,
with some jitter, for **72 hours** after the first attempt. Each attempt sends the same event `id` with a higher
`Nexafon-Delivery-Attempt`.

The first attempt starts within about a second of the event (p95).

## Endpoints that keep failing

An endpoint that fails for the whole 72-hour window is **turned off** and the workspace’s owners are notified by
email (“Webhooks to … are turned off”). Fix the receiver, send a test event, then turn the endpoint back on in
**Developers → Webhooks** or with `PATCH …/webhook-endpoints/{endpointId}` and `{"status": "active"}`.

## Delivery logs

`GET …/webhook-endpoints/{endpointId}/deliveries` lists every attempt: event, attempt number, status, response code,
latency, the start of any error, and the next retry. The dashboard shows the same log.

Stored events and attempts contain customer data, so they are deleted after a retention period (a little over two
weeks by default).

## Replays

`POST …/webhook-endpoints/{endpointId}/events/{eventId}/replay` sends a stored event again, with its original `id`, to
an active endpoint (a turned-off endpoint answers `webhook_endpoint_disabled`). Use it after fixing a bug in your
receiver.

All of these operations are in the [webhook endpoints reference](/v1/api/webhook-endpoints/); partners have the same
under `/api/v1/partner/webhook-endpoints` ([partner webhooks](/v1/partners/webhooks/)).