How to use the exponential backoff schedule generator
- Enter the first delay in seconds, the growth factor and an optional cap, the longest single wait.
- Enter the number of retries, up to 100.
- Choose a jitter style, or none, to see the range of each wait.
- Read the longest total wait and the table of delays and running totals, and use the CSV for configuration or documentation.
Formula
delay before retry n = min(cap, first delay x factor^(n - 1))
full jitter: random wait from 0 to the delay
equal jitter: random wait from half the delay to the delay
decorrelated jitter: random wait from the first delay to 3 x the previous wait, capped
Without a cap and with a factor of 2, the total of n delays is first delay x (2^n - 1). The page adds the lowest and the highest waits separately to give the shortest and longest total.
Doubling from one second, capped at one minute
With a first delay of 1 second, a factor of 2, a cap of 60 seconds and 8 retries, the waits are 1, 2, 4, 8, 16, 32, then 60 and 60 seconds, because 64 is above the cap. The total is 183 seconds, or 3 minutes and 3 seconds. The cap starts to apply at retry 7.
Without a cap, ten doubling retries from 1 second total 2^10 - 1 = 1,023 seconds, which is 17 minutes and 3 seconds. With full jitter, each wait is random between 0 and its delay, so the longest total stays the same but the shortest falls to zero and the average is about half. That spread is what keeps many clients from retrying at the same moment.
Why add jitter
If a service fails and a thousand clients all retry after exactly 1, 2 and 4 seconds, the retries arrive in synchronized waves that can keep the service down. Randomizing each wait spreads the load. Full jitter spreads it the most, equal jitter keeps a minimum wait, and decorrelated jitter makes each wait depend on the last so that clients drift apart.
A cap stops waits from growing to minutes or hours, and a limit on retries stops a client from trying forever. Choose both from how long a user or a calling system can wait.
Planning, not making requests
This page plans the waiting times only. It does not make requests, and real services may state their own retry rules, rate limits and requirements that a request is safe to repeat. Use the ranges to set timeouts in configuration, to explain a policy to a team, or to check the total time before giving up. The Cron Expression Generator helps with fixed schedules, the Time Duration Calculator adds up spans of time, and the Unix Timestamp Converter converts times in logs.
Assumptions and limits
- The first delay is the wait before the first retry, and the original attempt is not counted as a retry.
- Jitter is shown as ranges, not random samples, so the page gives the same answer every time.
- For decorrelated jitter the multiplier is 3 and the longest column follows the largest possible path.
- Time spent in the requests themselves is not included in the totals.
Frequently asked questions
What growth factor should I use?
A factor of 2 is the common default, which doubles the wait each time. A smaller factor such as 1.5 grows more slowly and tries more often. A factor of 1 gives a constant wait.
Which jitter style is best?
Full jitter spreads load the most. Equal jitter guarantees a minimum wait, which can be useful when a service needs time to recover. Decorrelated jitter spreads clients out over time. The right choice depends on your service and your clients.
What does the cap do?
It limits any single wait. Once the doubling reaches the cap, every later wait is the cap. Leave it blank for no limit, but then long runs of retries can wait very long.
How many retries are reasonable?
It depends on how long the work can wait and how costly a failure is. The page shows the total time for your choice so you can weigh a longer policy against the total wait.