---
title: Retries
description: Learn which Stormedo failures are retryable, how attempt limits work, and when Retry-After changes the next delivery time.
---

Stormedo retries temporary delivery failures using bounded exponential backoff. Each completed attempt includes the retry decision and the next retry time when another attempt is scheduled.

## Retryable outcomes

Stormedo retries these outcomes by default:

- DNS failures
- Connection failures
- Per-attempt timeouts
- HTTP `408 Request Timeout`
- HTTP `429 Too Many Requests`
- HTTP `5xx` responses

Normal HTTP `4xx` responses are not retried by default because they usually require a change to the request or destination.

## Quick-send attempt limits

The `retry` query parameter on `POST /send` counts retries after the initial attempt.

```text
POST /send?url=https://your-app.example/webhook&retry=3
```

This configuration permits four total attempts: one initial attempt and up to three retries.

`retry` accepts values from `0` through `19`.

## Advanced attempt limits

The advanced `POST /requests` API and SDK `maxAttempts` or `max_attempts` options count total attempts, including the initial call.

```json
{
  "url": "https://your-app.example/webhook",
  "retry": {
    "max_attempts": 4,
    "backoff": "exponential"
  }
}
```

This configuration also permits four total attempts.

## Retry-After

For retryable responses, Stormedo respects a valid `Retry-After` header when it requests a longer wait than the normal backoff.

The requested wait is bounded to 24 hours. Invalid values do not replace the normal retry policy.

## Per-attempt timeout

The default timeout is `50s`. Quick send accepts a whole-second or whole-minute timeout from `1s` through `5m`.

```text
POST /send?url=https://your-app.example/webhook&timeout=45s
```

The timeout applies to each delivery attempt, not the complete request lifecycle.

## Final failure

A request becomes `failed` when an outcome is not retryable or when no configured attempt remains. Completed attempts remain available through request detail and the dedicated attempt-history endpoint.