Retry Backoff Calculator
| # | Delay | Cumulative |
|---|---|---|
| 1 | 100ms | 100ms |
| 2 | 200ms | 300ms |
| 3 | 400ms | 700ms |
| 4 | 800ms | 1.5s |
| 5 | 1.6s | 3.1s |
| 6 | 3.2s | 6.3s |
| 7 | 6.4s | 12.7s |
| 8 | 12.8s | 25.5s |
About this tool
Why retry strategies matter
Network failures are inevitable in distributed systems. DNS timeouts, TCP connection resets, HTTP 503 responses, and database connection pool exhaustion are daily occurrences in production environments. Without proper retry logic, these transient errors become permanent failures that degrade user experience and trigger unnecessary alerts. However, naive retry approaches -- such as immediately retrying a failed request with no delay -- can make things worse. If a service is struggling under load, hammering it with instant retries from hundreds of clients adds more pressure and can turn a brief hiccup into a cascading outage. A well-designed retry strategy balances persistence (ensuring the request eventually succeeds) with restraint (giving the failing service time to recover). The right combination of backoff curve, delay parameters, and jitter determines whether your system recovers gracefully or collapses under its own retry traffic.
The thundering herd problem
When a service goes down, all connected clients begin retrying. If those clients use the same backoff parameters without jitter, their retries become synchronized: every client retries at the same intervals, creating periodic bursts of traffic. When the service finally recovers, it gets hit with a concentrated wave of requests from every waiting client simultaneously. This sudden surge -- called the thundering herd -- can immediately overwhelm the service and bring it back down, creating a cycle of failure and recovery that can persist for minutes or even hours.
Jitter solves this by adding randomness to each client's retry timing, spreading the load over time instead of concentrating it. Equal jitter provides a moderate spread by randomizing half of the computed delay while guaranteeing a minimum wait of 50% of the backoff value. Full jitter provides maximum spread by randomizing the entire delay between zero and the computed maximum, but it can occasionally produce very short delays. In practice, full jitter is preferred for large-scale systems because the improved distribution of retries outweighs the risk of occasional early retries.
Choosing the right strategy
Exponential backoff is the best default for most APIs and microservices. The doubling delay gives failing services progressively more breathing room and is the strategy recommended by AWS, Google Cloud, and Azure in their official documentation.
Linear backoff increases the delay by a fixed amount each attempt. It works well for rate-limited APIs where you need predictable, evenly spaced wait times, such as when respecting a Retry-After header.
Fixed backoff uses the same delay for every attempt. This is useful for polling scenarios where the wait time should be constant regardless of how many attempts have been made, such as checking a job status endpoint.
Fibonacci backoff follows the Fibonacci sequence (1, 1, 2, 3, 5, 8, 13...), producing growth similar to exponential but with a gentler start. It offers a middle ground when exponential growth feels too aggressive in the early attempts.
Most cloud providers (AWS, Google Cloud, Azure) recommend exponential backoff with full jitter as the default strategy. Use the calculator above to visualize how each strategy behaves with your specific parameters before implementing. For scheduling recurring jobs around your retry logic, see the Cron Parser. If you are debugging API authentication failures before retrying, the JWT Debugger can help inspect token expiration and claims.
Frequently Asked Questions
What is exponential backoff?
Exponential backoff is a retry strategy where each successive delay is multiplied by a fixed factor, typically 2. Starting from a base delay of 100ms, the sequence would be 100ms, 200ms, 400ms, 800ms, 1600ms, and so on. This geometric progression gives a failing service progressively more time to recover between each retry attempt. The approach is recommended by AWS, Google Cloud, and Azure for interacting with their APIs. Without exponential backoff, aggressive retries can overwhelm an already degraded service, turning a temporary issue into a prolonged outage. Most implementations also enforce a maximum delay cap (for example, 30 seconds) to prevent individual retries from waiting unreasonably long. Combined with jitter, exponential backoff is considered the gold standard for retry logic in distributed systems, microservice architectures, and any client communicating over unreliable networks.
Why use jitter in retry strategies?
Jitter introduces controlled randomness into retry timing to prevent synchronized retry storms. Consider a scenario where a database server goes down and 10,000 clients are all using exponential backoff with a 100ms base and a multiplier of 2. Without jitter, all 10,000 clients will retry at exactly 100ms, then exactly 200ms, then exactly 400ms -- creating periodic spikes that can overwhelm the server the moment it recovers. This is known as the thundering herd problem. Adding jitter randomizes each client's retry delay within a range, so instead of 10,000 simultaneous requests at 200ms, the retries spread across the full interval. AWS recommends full jitter in their architecture best practices. Google Cloud's API client libraries enable jitter by default. In production systems handling thousands of concurrent connections, jitter is not optional -- it is essential for maintaining stability during recovery from partial outages.
What is the difference between equal and full jitter?
Equal jitter and full jitter represent two approaches to adding randomness to retry delays. With equal jitter, the delay is calculated as half of the computed backoff value plus a random value between zero and the other half. For example, if the computed delay is 1000ms, the actual delay will be between 500ms and 1000ms. This guarantees a minimum delay of 50% of the computed value, providing moderate spread while ensuring retries are never too aggressive. Full jitter randomizes the entire delay between zero and the computed maximum. With a computed delay of 1000ms, the actual delay could be anywhere from 0ms to 1000ms. This provides maximum spread across the retry window, which is better for preventing thundering herds, but it means some retries may happen almost immediately. AWS's architecture blog specifically recommends full jitter for most use cases because the improved spread outweighs the occasional short delay.
How do I choose retry parameters?
Choosing retry parameters depends on your service characteristics and failure modes. For the base delay, match it to your service's typical response time: 100-200ms for fast APIs, 500ms-1s for database operations, and 1-5s for third-party integrations. A multiplier of 2 is the standard starting point and works well for most scenarios. Set the maximum delay based on your user experience requirements: 30 seconds for interactive requests, 60-120 seconds for background jobs. Limit attempts to 5-8 for user-facing operations (keeping total wait under 2 minutes) and up to 15-20 for critical background tasks. Always add full jitter in distributed systems where multiple clients may fail simultaneously. Services like Stripe recommend a maximum of 3 retries with exponential backoff for payment APIs. AWS SDKs default to 3 retries with a base of 100ms. Start conservative and increase retry counts only after monitoring shows that transient failures are being missed.