For most background jobs and distributed API clients, use bounded exponential backoff with jitter. It spaces retries farther apart as failures continue, while jitter helps prevent many clients from retrying in the same burst. For interactive actions or controlled polling, fixed intervals can be a better fit when predictable spacing matters and the latency budget allows it. Neither schedule is safe by itself: classify retryable errors, make repeated operations safe, follow service guidance, and limit total attempts or elapsed time.
How the two retry schedules differ
Fixed-interval retries
A fixed-interval policy waits the same amount of time after each failed attempt—for example, retrying every two seconds. Its timing is easy to predict and can suit regular polling or an operation with a strict, short response window. But if many clients encounter the same outage together, they may also retry together at each interval.
As an Amazon Associate I earn from qualifying purchases.
Exponential backoff
Exponential backoff increases the wait after successive failures, commonly doubling it until it reaches a configured cap. A sequence might start at roughly one, two, then four seconds. The longer waits reduce repeated request pressure during a prolonged problem, but can add noticeable delay if a service recovers shortly after a failure.
Recommended Free Tools
Jitter
Jitter adds randomness to retry timing. It helps spread out clients that failed at the same time, reducing the likelihood that they will create another concentrated wave of requests. Google Cloud IAM and AWS recommend jitter alongside backoff in their guidance (Google Cloud IAM; AWS Well-Architected Framework).
#1 Best Overall
Which strategy fits your workload?
| Situation | Better starting point | Why |
|---|---|---|
| Background job or distributed client; a dependency may be down or overloaded | Exponential backoff with jitter, a cap, and an overall deadline or attempt limit | Backoff reduces retry pressure over time; jitter helps avoid synchronized retries. |
| Interactive operation with a tight end-to-end latency budget | Immediate retry only if appropriate, or a short regular interval | Predictable spacing may fit a user-facing deadline better, but retries must not exceed that budget. |
| Controlled polling with a known cadence | Fixed interval, if the service contract and expected load support it | Steady spacing is straightforward; account for clients starting together or sharing a schedule. |
| Rate-limited request or response with server-specified retry timing | Follow the service’s retry guidance, within your own deadline and limits | A locally chosen schedule should not ignore timing information returned by the service. |
Microsoft Azure’s general guidance recommends exponential backoff with jitter for background work and immediate or regular-interval strategies for interactive work, subject to the end-to-end latency requirement (Microsoft Learn). Treat that as a workload-based starting point, not a universal rule.
How to build a retry policy safely
- Classify the failure. Retry only errors that are plausibly transient or explicitly designated retryable by the service. A permanent validation or authorization error is not fixed by repeating the request. Error codes are service-specific: for example, Google Cloud IAM recommends its documented strategy for 500, 502, 503, and 504 responses, but its guidance for 404 and 409/ABORTED is specific to IAM behavior (Google Cloud IAM).
- Check whether repeating the operation is safe. Reads are often easier to retry than writes, but do not assume a write is safe to repeat. Confirm that the operation is idempotent or use the service’s idempotency mechanism; otherwise, a retry may duplicate an effect. AWS warns that retries of non-idempotent calls can create unintended duplicate results (AWS Well-Architected Framework).
- Use one deliberate retry layer. Check whether the SDK, HTTP client, queue worker, or application already retries. Policies at several layers can multiply the actual attempts and load. AWS and Azure both call attention to the risks of excessive or layered retries (AWS Well-Architected Framework; Microsoft Learn).
- Set bounds on both waiting and work. Cap the interval, and also set a maximum attempt count or elapsed-time deadline. Include request timeouts and all retry waits in the end-to-end budget; a per-attempt cap alone does not bound the total time spent.
- Add jitter when clients may align. There are multiple valid forms, and their formulas are not interchangeable. Google IAM describes a truncated sequence of
min((2^n + random-fraction), maximum-backoff), wherenstarts at zero and a fresh random fraction no greater than one is used for each retry. AWS SDK full jitter instead usesrandom(0, 1) × min(20,000 ms, base_delay × 2^retry). These are examples from their respective documentation, not universal settings (Google Cloud IAM; AWS SDKs and Tools). - Honor server timing signals. RFC 9110 defines the HTTP
Retry-Afterfield as either an HTTP date or a delay in seconds. Azure recommends using response details such as retry guidance on a 503 response. AWS documentsx-amz-retry-afterbehavior for some services. Check the relevant API and client behavior, and keep the resulting wait within your operation’s deadline (RFC 9110; Microsoft Learn; AWS SDKs and Tools). - Observe and test retries. Track retry traffic and recurring failures so retries do not conceal a dependency problem or turn into a retry storm. Test transient failures, timeout behavior, and the final deadline with the actual SDK and configuration you deploy (AWS Well-Architected Framework).
Examples from cloud documentation are not universal defaults
Google Cloud IAM gives an example with waits beginning at one, two, and four seconds plus a random fraction, a maximum backoff (32 or 64 seconds are cited as typical values), and a configured deadline. Those are details of its documented IAM strategy, updated 2026-09-24; IAM’s stated error handling should not be generalized to every API (Google Cloud IAM).
The AWS SDK reference gives full-jitter examples with a 20,000 ms cap, a 50 ms base delay for transient non-throttling errors, and a 1,000 ms base delay for throttling errors. Those are values in that reference, where error category takes precedence over generic HTTP status classification—not settings to copy blindly into another client (AWS SDKs and Tools).
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Google Cloud Storage likewise lists retry defaults that vary by language and library. Its Java example includes a six-attempt maximum, one-second initial delay, 2.0 multiplier, 32-second maximum retry delay, and 50-second total timeout. Check the current client version, operation, and configuration before relying on those values (Google Cloud Storage).
Quick Recap
Decision rule
- Choose bounded exponential backoff with jitter for background or distributed work when repeated calls could amplify an outage.
- Choose a fixed interval or immediate retry for interactive or scheduled polling only when predictable timing fits the service contract and total latency budget.
- In either case, decide which errors qualify, verify operation safety, honor service timing signals, and bound total attempts or elapsed time.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
