Exponential Backoff Calculator
Plan retry delays with exponential backoff: base delay, multiplier, cap and full, equal or no jitter, with the wait before each retry and the total time spent.
Free · No sign-up · Your inputs stay in your browser
Input
Plan an exponential backoff with jitter
Output
Gives up after 0 ms – 92 s
| Retry | Wait before it | Elapsed by then |
|---|---|---|
| 1 | 0 ms – 500 ms | 0 ms – 500 ms |
| 2 | 0 ms – 1.0 s | 0 ms – 1.5 s |
| 3 | 0 ms – 2.0 s | 0 ms – 3.5 s |
| 4 | 0 ms – 4.0 s | 0 ms – 7.5 s |
| 5 | 0 ms – 8.0 s | 0 ms – 16 s |
| 6 | 0 ms – 16 s | 0 ms – 32 s |
| 7 | 0 ms – 30 s | 0 ms – 62 s |
| 8 | 0 ms – 30 s | 0 ms – 92 s |
JavaScript (attempt from 0)
const delay = Math.random() * Math.min(30000, 500 * 2 ** attempt);
Laravel job
public function backoff(): array { return [1, 1, 2, 4, 8, 16]; } public $tries = 9;
Laravel's backoff is in whole seconds and has no built-in jitter.
Without jitter, every client that failed at the same moment retries at the same moment, and the retries arrive as a second outage. Full jitter (a random delay between 0 and the exponential value) spreads them best, per the AWS Architecture Blog's comparison. Retry only what is safe to repeat: idempotent requests, or ones carrying an idempotency key.
Runs in this browser. Nothing you paste is sent to a server.
About this tool
Method, assumptions, practical next steps, and limits.
Jitter is not optional
When a dependency fails, all its clients fail at the same instant. Without jitter they all retry at the same instants too, and each wave of retries is a new outage. Full jitter, a random delay between zero and the exponential value, spreads them evenly; the AWS Architecture Blog's Exponential Backoff and Jitter measured the strategies against each other.
Only retry what is safe
Retrying a GET is safe; retrying a payment is safe only with an idempotency key the server uses to recognise the repeat. Retry on timeouts, 429 and 503, not on 400 or 422, which will fail the same way every time.