Exponential Backoff Calculator
The wait before each retry with exponential backoff, d = min(cap, base × factor^n), the range each wait can take with full or equal jitter, and the shortest, average and worst-case total time spent waiting.
Result…
How it's calculated
d_n = min(cap, base × factor^n), n = 0, 1, 2… No jitter: wait = d_n Full jitter: wait = random between 0 and d_n Equal jitter: wait = d_n ÷ 2 + random between 0 and d_n ÷ 2 Worst-case total = Σ d_n
Exponential backoff makes a client wait longer after each failed attempt before trying again, so a struggling service gets room to recover. The nth wait is the base delay multiplied by the growth factor n times, held below a cap. Jitter adds randomness so that many clients that failed together do not all retry at the same instant: full jitter picks any wait from zero up to the backoff value, and equal jitter keeps half of it and randomises the other half. These schemes are described in Marc Brooker's AWS Architecture Blog post "Exponential Backoff And Jitter". Because the waits are random, this calculator shows the range of each wait and the shortest, average and longest totals rather than one random draw.
Your numbers, step by step
About the Exponential Backoff calculator
This exponential backoff calculator lays out the retry schedule a client follows after failures. Enter the base delay in milliseconds or seconds, the growth factor, the maximum delay (cap) and the number of retries, and it works out each wait as d = min(cap, base × factor^n). Choose no jitter, full jitter or equal jitter and it shows the range each wait can fall in, rather than one random draw, so the answer is the same every time. It totals the shortest possible, average and worst-case time spent waiting, shows the retry where the cap takes over, and draws the waits as bars. Developers use it to set retry policies for API clients, queues and network calls, and to check that a policy gives up within a timeout. Each retry is listed in the working.
How to use it
- Enter the “Base delay” and choose its “Time unit”.
- Set the “Growth factor” (2 doubles each wait) and the “Maximum delay (cap)” in the same unit.
- Enter the “Number of retries” and pick the “Jitter” scheme.
- Read the worst-case total wait, then the shortest and average totals and each retry's range in the working.
Worked example
With a base of 100 ms, a factor of 2, a cap of 10,000 ms and 8 retries, the waits are 100, 200, 400, 800, 1600, 3200 and 6400 ms, and the eighth would be 12,800 ms but is capped at 10,000 ms. The worst case is 22,700 ms, or 22.7 s. With equal jitter each wait falls between half and all of its value, so the total is between 11,350 and 22,700 ms, with an average of 17,025 ms.
Updated
Questions people ask
What is the formula for exponential backoff?
The wait before retry n is min(cap, base × factor^n), counting n from 0. With a base of 1 s and a factor of 2 the waits are 1, 2, 4, 8 s and so on until the cap.
What is the difference between full jitter and equal jitter?
Full jitter picks a random wait between 0 and the backoff value. Equal jitter keeps half of the backoff value and adds a random amount up to the other half, so a wait is never shorter than half its value.
Why add jitter to retries at all?
Without it, clients that failed at the same moment retry at the same moments too, hitting the service in waves. Marc Brooker's Exponential Backoff And Jitter post on the AWS Architecture Blog compares the schemes.
How long will all my retries take in the worst case?
Add up every capped wait. The worst-case total here counts only the waiting, so add the time each attempt takes, including any timeout, for the full time before the client gives up.
What is a common mistake when setting a retry policy?
Leaving out the cap, so waits grow far beyond anything useful, or retrying errors that will never succeed. Check how your client library counts the first attempt, and pair backoff with the limits in the rate limit calculator.