Compute an exponential backoff schedule for retries

Provide the delay before the first retry, the growth multiplier, the maximum permitted delay, and the number of attempts. The result shows the wait before every retry in the same time unit you supplied. It is useful for checking configuration, documenting client behavior, comparing policies, and catching unexpectedly long recovery windows before retry logic reaches production.

Define the retry policy in one consistent unit

Start with the base delay, which is the wait before retry attempt one. Choose a unit that matches the system you are configuring, such as milliseconds or seconds, and use that same unit for the maximum delay. The calculator deliberately leaves the unit open because exponential backoff has the same arithmetic in every unit. The multiplier controls how quickly the uncapped delay grows. A multiplier of two doubles each successive wait, while one produces a constant interval. Finally, attempts means retry attempts, not the initial operation: entering five produces five delay records numbered one through five. Keeping that distinction explicit prevents a common off-by-one error in runbooks and configuration reviews. The base delay must be positive, the multiplier must be at least one, the maximum must be positive, and the attempt count must be a whole number from one through one thousand. These constraints keep the schedule meaningful and its output bounded. If your application accepts values in milliseconds, label copied results accordingly so nobody later interprets them as seconds.

Understand growth and the maximum-delay cap

For retry number n, the uncapped delay is the base delay multiplied by the multiplier raised to n minus one. The returned delay is the smaller of that value and the maximum delay. For example, a base of 250, multiplier of two, and maximum of 2,000 yields 250, 500, 1,000, 2,000, and then 2,000 again for all later attempts. The cap applies even when it is below the base delay, so a base of ten with a maximum of three returns three from the first attempt onward. That behavior mirrors a strict maximum and makes unusual configurations visible instead of silently rewriting them. The implementation advances iteratively rather than relying on an unbounded exponent, and it stops growth once the cap has been reached. This keeps very large multipliers deterministic without allowing an infinite intermediate value to leak into the JSON result. The schedule contains no random jitter. That is intentional: it exposes the underlying deterministic policy that jitter would modify, making the result suitable for tests, documentation, and comparisons. Add jitter separately according to your client library's precise rules.

Apply the schedule without creating a retry storm

Use the output to review the timing envelope before you ship a retry policy. A short base delay may look harmless, yet a high multiplier can quickly push later attempts to the cap and stretch the total recovery window. Compare the individual waits with request timeouts, queue visibility periods, rate-limit reset times, and the maximum duration users will tolerate. The calculator reports waits before retries; it does not include the duration of the original request or the work performed during each failed attempt. Sum those durations separately when estimating a complete worst-case operation. In distributed systems, deterministic schedules can cause many clients to retry simultaneously after a shared outage. Production clients commonly add bounded random jitter to spread that load, while preserving the computed schedule as the upper bound or central value. This capability does not execute requests, sleep, contact a service, or decide whether an error is retryable. It only computes the arithmetic schedule, with no network access or stored state. That separation makes it safe to use in configuration generators and automated policy checks. Browser execution is free, while API automation is charged at $0.002 per request.