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

# Webhook Delivery Retries and Guarantees

> InfraAudit retries failed webhook deliveries up to 3 times with exponential backoff. Learn the retry schedule, timeout window, and how to recover missed events.

InfraAudit delivers webhook events with at-least-once semantics and retries failed deliveries using exponential backoff. Understanding the retry behavior helps you build a reliable receiver.

## Delivery guarantees

* **At-least-once:** InfraAudit may deliver the same event more than once — for example, if your endpoint acknowledges after a network timeout on InfraAudit's side. Use the `delivery_id` field in each payload to deduplicate.
* **No ordering guarantee:** Events may arrive out of order if retries from one delivery overlap with a later successful delivery.

## What counts as success

A delivery succeeds if your endpoint returns any `2xx` HTTP status code within **10 seconds**.

A delivery fails if:

* The endpoint returns a `4xx` or `5xx` status
* No response is received within 10 seconds
* The connection is refused or the DNS lookup fails

InfraAudit only checks the status code — the response body is ignored.

## Retry schedule

| Attempt   | Delay after previous attempt |
| --------- | ---------------------------- |
| 1st retry | 5 minutes                    |
| 2nd retry | 30 minutes                   |
| 3rd retry | 2 hours                      |

After all 3 retries are exhausted (roughly 2.5 hours from the initial attempt), the delivery is marked `failed` and no further retries occur.

## Viewing delivery history

From the web UI, go to **Settings → Webhooks → \[webhook name] → Deliveries**. Each delivery record shows:

* Event type and delivery ID
* Attempt number and HTTP status returned
* Response time
* Request and response headers for debugging

Via the API:

```bash theme={null}
GET /api/v1/webhooks/{webhook_id}/deliveries
```

## Handling failures

If deliveries are consistently failing:

<Steps>
  <Step title="Check the delivery history">
    Look at the HTTP status code. A `401` means your endpoint is rejecting the signature. A `5xx` means your application is erroring.
  </Step>

  <Step title="Fix your receiver">
    Resolve the issue within the 2.5-hour retry window to avoid losing events.
  </Step>

  <Step title="Recover missed events from the API">
    For events that exhausted all retries, query the corresponding InfraAudit API endpoint directly — for example, `GET /api/v1/drifts/{id}` for a missed `drift.detected` event.
  </Step>
</Steps>

<Note>
  Manual retry of failed deliveries is not yet available in the UI or API. Use the InfraAudit API to fetch missed data directly.
</Note>

## Disabling a webhook during maintenance

To suppress deliveries while your endpoint is down, disable the webhook:

```bash theme={null}
PUT /api/v1/webhooks/{id}
Content-Type: application/json

{ "enabled": false }
```

Re-enable it after maintenance. Events that fired while the webhook was disabled are **not** replayed — query the API for any data you need from that window.