Retry back-off calculator
See every retry delay and the total wait for exponential back-off with jitter, then copy the Spring or Resilience4j configuration.
| Retry | Shortest | Expected | Longest | Sample |
|---|
Design a retry schedule you can reason about
Every client that calls another service needs a retry policy, and the policy has a few parameters whose combined effect is hard to see in your head: a base delay, a multiplier, a maximum delay, a maximum number of attempts and a jitter strategy. Set them badly and you either give up too soon or retry so aggressively that you turn a small outage into a big one.
Enter the parameters and the calculator shows the schedule attempt by attempt: the shortest and longest possible wait, the expected wait and one random sample, plus the total time a caller can spend waiting in the best, expected and worst case. Compare no jitter, full jitter, equal jitter and decorrelated jitter, then copy ready-made configuration for Spring Retry, Resilience4j or a Spring Kafka back-off. The total worst-case time is the number to check against your timeouts: a request that retries for ten minutes may outlive the user's patience, a gateway timeout or a Kubernetes probe.
Good habits
- Cap the delay (30 to 60 seconds is common) and the number of attempts.
- Always use jitter for calls from many instances.
- Retry only idempotent operations or use idempotency keys.
- Combine retries with timeouts and a circuit breaker, so a dead dependency is not retried by every request at once.
Samples change on every calculation because jitter is random. Everything is computed in your browser.
Frequently asked questions
What is exponential backoff?
After each failed attempt the client waits longer before retrying, typically doubling the delay up to a maximum. It gives a struggling service room to recover instead of hammering it at a constant rate.
Why add jitter?
Without randomness, every client that failed at the same moment retries at the same moment (a thundering herd) and the service fails again. Jitter spreads the retries over time. AWS found full jitter and decorrelated jitter finish the work with far fewer calls than plain exponential backoff.
What is the difference between full, equal and decorrelated jitter?
Full jitter picks a random delay between 0 and the exponential delay. Equal jitter keeps half the delay and randomises the other half. Decorrelated jitter bases the next delay on the previous one (random between the base and three times the previous delay).
Which errors should I retry?
Only transient, idempotent failures: timeouts, connection resets, HTTP 429, 502, 503 and 504. Do not retry 4xx client errors (other than 408 and 429) or non-idempotent calls without an idempotency key.