Exponential Backoff

Updated September 30, 20263 min read

In short

Exponential backoff is a retry strategy that waits longer after each failed attempt, such as 1, 2, 4 and 8 seconds, so a struggling service can recover.

What is exponential backoff?

When a network call fails, retrying immediately in a tight loop usually makes things worse: if the server is overloaded, a flood of instant retries only adds more load. Exponential backoff spaces retries out by multiplying the wait after each failure, typically doubling it. A client might wait 1 second, then 2, then 4, then 8, up to a maximum delay and a maximum number of attempts, before giving up and reporting the error.

Real implementations add jitter, a random variation in each delay. Without it, thousands of clients that failed at the same moment would also retry at the same moments, hitting the server in synchronized waves, a problem known as the thundering herd. A popular approach called full jitter picks a random delay between zero and the current exponential limit. Clients should also respect a Retry-After header when the server sends one, for example with a 429 Too Many Requests or 503 Service Unavailable response.

Exponential backoff is like calling a busy friend: if they don't answer, you try again in a minute, then in five minutes, then in an hour, rather than calling fifty times in a row. It is built into HTTP clients, cloud SDKs, message queue consumers, database drivers, and background job systems, and it appears in low-level protocols too: classic Ethernet used binary exponential backoff to recover when two devices transmitted at the same time.

Backoff is only half of a good retry policy. Retry only errors that are likely to be temporary, such as timeouts, dropped connections, 429, and 5xx responses, never errors like 400 Bad Request or 401 Unauthorized, which will fail the same way every time, and retry only idempotent operations, or use idempotency keys, so a retried payment doesn't charge a customer twice. Backoff is also different from a circuit breaker: backoff slows down retries of individual requests, while a circuit breaker stops sending requests to a failing service altogether for a while.

Key takeaways

Each retry waits longer than the last, usually doubling the delay.
Random jitter keeps many clients from retrying in lockstep.
Cap both the maximum delay and the number of attempts.
Retry only temporary failures, and only operations that are safe to repeat.
Honor a server's Retry-After header when it sends one.

Example

Retrying a request with exponential backoff and full jitterjavascript

async function fetchWithRetry(url, maxAttempts = 5) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const res = await fetch(url).catch(() => null); // network error -> null
    if (res && res.status !== 429 && res.status < 500) return res; // success or permanent error
    if (attempt === maxAttempts - 1) break;
    const limit = Math.min(30_000, 1000 * 2 ** attempt); // 1s, 2s, 4s, 8s... capped at 30s
    const delay = Math.random() * limit;                  // full jitter
    await new Promise((resolve) => setTimeout(resolve, delay));
  }
  throw new Error("Request failed after " + maxAttempts + " attempts");
}

Readers ask

Why add jitter to exponential backoff?

Without jitter, clients that failed together retry together, creating repeated traffic spikes that can keep a recovering server down. Randomizing each delay spreads the retries out evenly over time.

How many times should I retry a failed request?

For user-facing requests, 3 to 5 attempts with delays capped at a few tens of seconds is common. Background jobs can retry for much longer, and work that still fails is usually reported or moved to a dead-letter queue.

What is the difference between exponential backoff and rate limiting?

Rate limiting is enforced by a server to cap how many requests a client may send. Exponential backoff is how a well-behaved client reacts when requests are rejected or the server is failing.