> ## Documentation Index
> Fetch the complete documentation index at: https://docs.riverside.fm/llms.txt
> Use this file to discover all available pages before exploring further.

# Delivery & Retries

> How Riverside delivers webhooks, retries failures, auto-disables broken endpoints, and lets you replay.

## What counts as success

A delivery succeeds when your endpoint returns any **`2xx`** status within the request timeout (**10 seconds**). Anything else is a failure and is retried:

* Non-`2xx` status codes (`4xx`, `5xx`).
* Timeouts, DNS failures, and connection errors.
* Redirects — a `3xx` is **not followed** and is treated as a failure (this prevents a redirect from re-targeting your signed payload).

Riverside reads only a truncated snippet of your response body for the delivery log, so the content of your response doesn't matter — only the status code.

## Retry schedule

Failed deliveries are retried on an exponential backoff. The default schedule is:

| After failed attempt | Wait before next attempt |
| :------------------- | :----------------------- |
| 1st                  | +5 minutes               |
| 2nd                  | +30 minutes              |
| 3rd                  | +2 hours                 |

That's **up to 4 attempts total** (the initial attempt plus 3 retries). The `delivery_attempt` field in the [envelope](/webhooks/overview#the-event-envelope) tells you which attempt you're receiving, and each attempt is recorded in the delivery history.

<Info>
  Because failures are retried, the same event may reach you more than once. Always **deduplicate on the envelope `id`**. Delivery order is not guaranteed either — use `event_ts` if order matters.
</Info>

## Auto-disable

If a delivery exhausts all retries, it is marked **`FAILED`** and the subscription is **automatically disabled** — no further events are delivered until you re-enable it.

To recover:

1. Fix your endpoint.
2. Re-enable the subscription.
3. Optionally [replay](#replaying-deliveries) the deliveries that failed while it was down.

<Tip>
  Auto-disable protects your endpoint and ours from piling up doomed deliveries. Monitor for disabled subscriptions if uptime matters to you — re-enabling does not retroactively resend events that occurred while disabled unless you replay them.
</Tip>

## Replaying deliveries

Any individual delivery can be re-queued for another attempt — useful after fixing a bug in your handler or re-enabling a subscription. Replaying re-sends the same event envelope (with an incremented `delivery_attempt`) through the normal delivery path. The subscription must be enabled for the replay to be delivered.

## Debugging failed deliveries

Use the delivery history to see, per attempt, the response code, a snippet of your endpoint's response body, any error message, and the request duration. Filter by `status: FAILED` to find deliveries that need attention.
