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

# Retries & Delivery Logs

> How Bluvo retries failed deliveries and how to inspect delivery history

## What counts as success

A delivery is considered successful when your endpoint returns any **2xx** HTTP status code. Any other response (or a timeout) triggers a retry.

## Retry schedule

Failed deliveries are retried with **exponential backoff**, capped at 240 seconds. The delay formula is:

```
delay = min(1000ms * 2^attempt, 240000ms)
```

| Attempt | Delay       | Cumulative time |
| ------- | ----------- | --------------- |
| 1       | 1 second    | 1s              |
| 2       | 2 seconds   | 3s              |
| 3       | 4 seconds   | 7s              |
| 4       | 8 seconds   | 15s             |
| 5       | 16 seconds  | 31s             |
| 6       | 32 seconds  | \~1 min         |
| 7       | 64 seconds  | \~2 min         |
| 8       | 128 seconds | \~4 min         |
| 9       | 240 seconds | \~8 min         |
| 10      | 240 seconds | \~12 min        |

After **10 failed attempts**, the delivery is marked as `failed` and no further retries are made.

<Info>
  Retries are backed by Durable Object alarms, which means they survive infrastructure restarts and are guaranteed to execute.
</Info>

## Request timeout

Each delivery attempt has a **30-second timeout**. If your server doesn't respond within 30 seconds, the attempt is treated as a failure and the next retry is scheduled.

<Tip>
  Return a `200` response immediately and process the event asynchronously. This prevents timeouts and ensures reliable delivery.
</Tip>

## Delivery statuses

| Status    | Meaning                                                     |
| --------- | ----------------------------------------------------------- |
| `pending` | Delivery is in progress or awaiting retry                   |
| `success` | Your endpoint returned a 2xx response                       |
| `failed`  | All 10 retry attempts were exhausted without a 2xx response |

## Viewing delivery logs

In the [Bluvo Portal](https://portal.bluvo.dev), navigate to **Settings > Webhooks**, select an endpoint, and click **Deliveries** to view the log.

Each delivery record includes:

| Field           | Description                                                              |
| --------------- | ------------------------------------------------------------------------ |
| Event type      | The webhook event (e.g., `wallet.created`)                               |
| Event ID        | The unique `eventId` from the payload                                    |
| Status          | `pending`, `success`, or `failed`                                        |
| Attempts        | Number of delivery attempts made                                         |
| Response status | HTTP status code returned by your server                                 |
| Response body   | First 1,000 characters of the response body                              |
| Error message   | Error details if the delivery failed (e.g., timeout, connection refused) |
| Timestamps      | When the delivery was created and last attempted                         |

## Tips

<AccordionGroup>
  <Accordion title="Respond fast, process async">
    Immediately return `200 OK` and enqueue the event for asynchronous processing. This prevents timeouts and keeps retry counts low.
  </Accordion>

  <Accordion title="Don't rely on delivery order">
    Events may arrive out of order, especially when retries are involved. Use the `timestamp` field in the payload to determine event ordering if needed.
  </Accordion>

  <Accordion title="Deduplicate with eventId">
    The same event may be delivered more than once. Track processed `eventId` values to avoid duplicate handling.
  </Accordion>

  <Accordion title="Monitor for failed deliveries">
    Regularly check the delivery logs in the Portal. If an endpoint consistently fails, verify the URL is reachable and returning 2xx responses.
  </Accordion>
</AccordionGroup>