Retry with backoff
Also called: exponential backoff, backoff and retry, retry with jitter.
When a request fails for a reason that may pass, try again, but wait longer before each new try (for example 1 s, 2 s, then 4 s). A little randomness, called jitter, stops many clients from retrying at the same moment.
The server is down for 3 s. With backoff, each retry waits twice as long as the one before (0.5 s, 1 s, 2 s), so the save works on the 4th try. Without it, the page hammers the server every 150 ms.
Say it in a prompt
Retry failed calls to the shipping API only on network errors, 429 and 5xx responses. Make at most 4 tries, waiting 1 s, 2 s, then 4 s with ±20% random jitter, and use the Retry-After header instead when the server sends one. Show "Still trying…" after the second failure. Seen on
- AWS SDKs: The standard retry mode retries throttling and short-lived errors with exponential backoff and jitter, making 3 attempts in total by default.
- Stripe API: The rate limits guide says to retry 429 responses on an exponential backoff schedule with added randomness.
You might describe it as
- try again a few times but wait longer each time
- don't give up on the first network error
- automatic retries that slow down so the server can recover
Not to be confused with
- Request timeout
Backoff decides when to try again after a failure; a timeout decides when to stop waiting for an answer.
- Idempotent request
Retry with backoff sends the same request again; an idempotent request is what makes that safe, so a retry can't do the work twice.
- Rate-limit message (429)
Backoff is the code slowing down its own retries; a rate-limit message is what a person sees when the server answers 429.