# Delivery, Retries & Health

Echo retries failed deliveries persistently, and only deregisters a webhook that has been failing continuously for days. This page covers what counts as a failure, how retries are scheduled, and how deregistration works.

## What Counts as a Failed Delivery

An attempt fails when any of these occur:

- **Non-success status code:** anything other than `200 OK`, `202 Accepted`, or `204 No Content`
- **Timeout:** no response within 15 seconds
- **Connection failure:** network or SSL/TLS errors


Every failure triggers a retry and counts toward the [failure threshold](#webhook-health-and-deregistration).

## Retry Schedule

Failed deliveries are retried on a repeating exponential backoff cycle:

```text
5 min → 10 min → 20 min → 40 min → 80 min → (cycle repeats: 5 → 10 → ...)
```

- Delays never exceed **80 minutes**
- Retries continue on this cycle until delivery succeeds or the webhook is [deregistered](#webhook-health-and-deregistration); there is no fixed time cap, and the 2-day figure below is a deregistration floor, not a retry ceiling
- The **payload is identical** on every retry; only the delivery headers change (`X-Echo-Retry-Attempt` increments, `X-Echo-Timestamp` updates, `X-Echo-Webhook-Id` stays the same; see [Request Headers](/echosync-webhooks/technical-implementation))


## Webhook Health and Deregistration

Health is tracked **per registered webhook, that is, per event type**. Each webhook you register has its own independent failure counter and deregistration clock; one webhook's failures never affect another's health.

Within a webhook, failures accrue on a single running counter: any failed delivery increments it, and any successful delivery resets it to zero.

**Deregistration requires both conditions, per webhook:**

1. **25 or more failed deliveries in a row** (uninterrupted by any success) **and**
2. **2 or more days** have elapsed since the first failure


**Any single successful delivery resets that webhook's failure count and timer.** One success is a fresh start.

This design is deliberately forgiving: a maintenance window or an overnight outage won't cost you your registration, and you have up to 2 days to resolve issues even without 24/7 monitoring.

**Example:** your webhook fails 25 deliveries in a row over three days; both conditions are met, and that webhook is deregistered. If any one of those deliveries had succeeded along the way, the counter and the clock would have reset, and delivery would have continued uninterrupted.

### What Happens at Deregistration

1. Delivery for that webhook stops immediately
2. An email is sent to your registered contact explaining the deregistration
3. No further deliveries of that event type are sent or queued; your other webhooks are unaffected


### Reactivation

A deregistered webhook requires **full re-registration**, the same process as [initial onboarding](/echosync-webhooks/getting-started), including validation payloads. The reactivated webhook starts with a clean failure count.

## Monitoring Recommendations

To catch problems before they reach the failure threshold:

- **Track** successful receipts, response times, and signature verification results
- **Alert** on response times approaching 15 seconds and on rising failure rates
- **Log** each `X-Echo-Webhook-Id` with timestamps, retry attempt, and processing outcome


When troubleshooting, start with the `X-Echo-Webhook-Id` values in your logs, check endpoint availability and response times, and re-test signature verification with the [worked example](/echosync-webhooks/technical-implementation). If issues persist, contact Echo's Technical Integrations team with the webhook Ids and timestamps.