Exponential Linear Fixed

Initial Delay (ms) Max Retries (excludes initial request) Max Delay Cap (ms, optional) Backoff Factor (> 1)

Explain chart math

Hover the chart to substitute a specific retry number.

Time Unit

Total Retries

Final Retry Delay

Total Cumulative Wait

Retry #	Delay (ms)	Expected Delay (ms)	Max Delay (ms)	Cumulative Delay (ms)
Adjust inputs to generate a schedule.

Retry logic helps absorb transient errors like short network drops, brief overloads, or temporary upstream unavailability. Backoff matters because immediate repeated retries can amplify incidents. Increasing delay gives systems time to recover and reduces repeated pressure.

Exponential: Delay grows by a multiplier each retry. Strong pressure reduction and usually the safest default when failure behavior is unknown.
Linear: Delay increases by a fixed step each retry. Easier to reason about when you want gradual, predictable delay.
Fixed: Delay stays constant for every retry. Useful when you need a strict retry cadence or very simple behavior.

For simple or small systems, any retry strategy can work. It is fine to pick something simple.

For complex or distributed systems, the best retry strategy is generally an exponential backoff. The overall goal is to:

allow the system to absorb a small number of intermittent failures
cap the amount of the traffic the system gets during broad failures

Without backoff, a system with consistent request traffic will begin compounding requests endlessly during downtime, and even if the root cause is fixed, it may never recover due to the amount of requests that have piled up and are retrying.

In general, you want to employ many strategies to cap the amount of traffic your system can receive during an incident or other failure mode.

exponential backoff on retries
cap the number of retries
selective retries for only certain error modes
global circuit breaker

Jitter is randomization around each retry delay. In systems with many clients, it keeps clients from retrying at the exact same time causing periodic spikes in requests.

Use jitter when many clients can fail together, when upstreams enforce rate limits, or when synchronized retries could create retry storms.

None: Uses the deterministic delay exactly. Simple to predict, but clients stay synchronized.
Equal: Retries happen between 50% and 100% of the computed delay. This is a balance of spread but with a guaranteed minimum wait.
Full: Retries happen between 0% and 100% of the computed delay. This maximizes spread and best reduces synchronized spikes.

Jitter mode comparison
Good Use Case	None	Equal	Full
Few concurrent clients	Yes	Yes	Yes
Need deterministic retry timing for debugging or audit traces	Yes	No	No
Many clients may retry together after the same failure	No	Yes	Yes
Want randomness but still reasonably bounded	No	Yes	No
Want to reduce retry storms	No	Yes	Yes
Need a strict minimum wait before each retry	Yes	Yes	No