Exponential Backoff Calculator

A retry policy where the wait before each retry grows by a constant factor, up to a cap. The AWS Architecture Blog post "Exponential Backoff And Jitter" (Marc Brooker, March 4, 2015) describes capped exponential backoff as clients that "multiply their backoff by a constant after each attempt, up to some maximum value", and its simulator computes it as min(cap, base × 2^n). This calculator takes n as the number of previous retries, so retry 1 uses n = 0 and waits the base: with a 1,000 ms base, a multiplier of 2 and a 32,000 ms cap, the first five retries wait 1, 2, 4, 8 and 16 seconds, and every later retry waits the cap. The AWS simulator counts the failed attempt first, so its first retry sleeps 2 × base and the same inputs give 2, 4, 8, 16 and 32 seconds; the curve is identical, shifted by one step. The point is to stop hammering a service that just failed, while still finishing quickly when the failure was a blip.

Because backoff alone keeps clients synchronized. Every caller that failed in the same instant computes the same delay and retries in the same instant, so the load arrives in spikes with idle gaps between them. The AWS post puts it this way: with plain backoff "we've just introduced times when no client is competing", and "the solution isn't to remove backoff. It's to add jitter." Randomizing each delay spreads the retries out toward a steady rate. The post's conclusion: "The return on implementation complexity of using jittered backoff is huge."

Full jitter, unless you have a measured reason not to. The AWS post simulated contending clients against a shared resource and reports that equal jitter is "the loser": it does slightly more work than full jitter and takes much longer. Full jitter and decorrelated jitter were close: the post calls the decision between them "less clear", the "Full Jitter" approach "uses less work, but slightly more time", and decorrelated jitter made more calls. The post's own recommendation is jittered backoff in general ("it should be considered a standard approach for remote clients"), not one variant; full jitter is this tool's default because it did the least client work. Full jitter is sleep = random_between(0, min(cap, base × 2^n)). Equal jitter keeps half the backoff and randomizes the other half, so no retry is near-instant. Decorrelated jitter draws each sleep from the previous one, sleep = min(cap, random_between(base, sleep × 3)), so it does not depend on the attempt number at all. The calculator shows the sampled delay, the min–max range and the expected value for each so you can see the trade-off in your own numbers.

Back off, and read the header first. RFC 6585 section 4 defines 429 as "the user has sent too many requests in a given amount of time ('rate limiting')" and says the response "MAY include a Retry-After header indicating how long to wait before making a new request". When that header is present, wait that long, within a cap: the server knows its own quota window and your computed delay is a guess, but a bogus or enormous value must not stall the client for days, so the generated code clamps Retry-After at 10 minutes (lower it to your caller's deadline). When it is absent, fall back to exponential backoff with jitter. Two more rules from the same RFC: 429 responses "MUST NOT be stored by a cache", and the specification does not define how the server identifies a user or counts requests, so read the API's rate-limit documentation for the actual window.

Either an HTTP-date or a number of seconds. RFC 9110 section 10.2.3 defines Retry-After = HTTP-date / delay-seconds, where "a delay-seconds value is a non-negative decimal integer, representing time in seconds". The RFC's own examples are "Retry-After: Fri, 31 Dec 1999 23:59:59 GMT" and "Retry-After: 120". With a 503 (Service Unavailable) response it says how long the service is expected to be unavailable; with a 3xx redirect it is the minimum time to wait before following the redirect. The "Test a Retry-After header value" field in this tool parses either form, and the generated code does the same: an all-digit value is seconds; one of the three HTTP-date shapes in RFC 9110 section 5.6.7 (IMF-fixdate like the example above, or the obsolete RFC 850 and asctime forms) is a date; anything else, including "1.5", "-1", "1e3" or an ISO 8601 timestamp, is not guessed at and falls back to the computed backoff. The one exception is the curl loop, which honors only delay-seconds (an HTTP-date falls back to the computed backoff), because parsing a date portably in bash is not worth the lines.

Transient ones. Google Cloud's retry strategy documentation for Cloud Storage lists "HTTP 408, 429, and 5xx response codes" as responses that "indicate transient problems that are useful to retry", along with socket timeouts and TCP disconnects. Other 4xx responses (400, 401, 403, 404, 422) mean the request itself is wrong and will fail the same way again, so retrying them only adds load. The generated snippets retry 408, 429 and anything 500 and above, plus network errors such as DNS failures and connection resets, and return or raise everything else immediately.

All five snippets follow one contract. A response with any status outside 408, 429 and 5xx ends the loop at once: JavaScript, TypeScript, Python and Go hand that response back, whether it is a 200 or a 404, so the caller inspects the status; the bash script's only return value is its exit code, so it exits 0 for 2xx and 3xx and exits 2 for anything else that is not retried, which keeps a 401 or 404 from passing a health check. When the retries are used up on a retryable status, JavaScript and TypeScript return the last response (like fetch, an HTTP status never throws), Python raises requests.HTTPError with the last response on error.response, Go returns nil and an error naming the status, and bash exits 1. A network failure on the final attempt throws, raises or returns the error in the same way, and bash exits 1 for it too. With "Honor Retry-After" on, every snippet reads the header on every retried response, treats an all-digit value as seconds and one of the three RFC 9110 date shapes as a date (bash reads seconds only), clamps the result to 10 minutes, and falls back to the computed delay for anything else.

An idempotent request can be repeated without changing the outcome, so a retry after an ambiguous failure (a timeout where the first request may or may not have been processed) is safe. Google Cloud's retry documentation warns that "retrying requests that are not idempotent can lead to race conditions and other conflicts" and sorts its operations into three groups: always idempotent (all get and list requests, creating or deleting a bucket, deleting an HMAC key or notification), conditionally idempotent (writes that carry a precondition such as an etag or generation match, and deleting an object with a generation match, which "are only idempotent if they include specific optional arguments"), and never idempotent (for example creating a notification or a new key). Apply the same test to your own API: a POST that charges a card or sends an email needs an idempotency key before it is safe to wrap in a retry loop.

A retry budget is the total time or total number of extra requests a caller is allowed to spend on one logical operation. Max retries bounds the count; the "Total wait" and "Range" tiles in this tool bound the time, and the worst case is the number to compare with your caller's deadline. Google Cloud's own client libraries ship with such limits: the retry strategy page lists, for example, a maximum retry delay of 32 seconds and a total timeout of 50 seconds for the Java client, a 64-second maximum wait and a 600-second default deadline for Node.js, and a 60-second maximum wait with a 120-second default deadline for Python. Also keep retries at one layer: if a gateway, an SDK and your own loop each retry three times, one failure can turn into dozens of requests.

Full jitter draws uniformly between 0 and the capped exponential, so its mean is half of it. Equal jitter keeps half and draws the other half uniformly, so its mean is three quarters. Decorrelated jitter has no closed form because each delay depends on the previous draw and on the cap, so the tool averages 2,000 simulated runs and labels the result as a simulation mean. The "This sample" tile is one concrete draw from a seeded random generator, and "Re-roll jitter" draws the next one.

No. The schedule, the simulation and the code snippets are computed in your browser with JavaScript. Nothing you type is uploaded, and no account is needed.