Exponential Backoff

Retrying a failed call with a wait that doubles each time (1s, 2s, 4s), plus randomness, so you stop hammering a struggling service.

wait longer each time it failsdon't hammer itretry with a delayexponential back-offbackoff and jitterretry after 1s then 2s then 4sstop spamming the api after errorssmart retry

See it

Live demo coming soon

What it is

Instead of retrying instantly, you wait base * 2^attempt before each try: 1s, 2s, 4s, 8s, capped at some ceiling. Then you add jitter, a random spread on each delay, so a thousand clients that all failed at the same moment do not all come back at the same moment. AWS's 'Exponential Backoff and Jitter' write-up is the canonical reference, and 'full jitter' (sleep a random amount between zero and the computed delay) is the variant that survives real load.

Retry only what the API itself treats as transient: 429 rate limits, connection resets, timeouts on idempotent operations, and the 5xx codes that mean 'try again' rather than 'never' (503 yes, 501 Not Implemented no, that endpoint will still not exist in four seconds). Do not retry 400, 401, 403, or 422, because a malformed request stays malformed. A 404 is usually permanent too, with one exception worth knowing: on an eventually consistent API, something you created a second ago can 404 briefly, which is the rare case where a bounded retry is right. If the server sends a 'Retry-After' header, obey it; the server knows more than your formula does.

Gotcha: retries pile load onto a system precisely when it is weakest, and nested retries (SDK retries inside your retries inside a queue's retries) quietly multiply into a stampede. Cap attempts at three to five, cap total elapsed time, put a circuit breaker in front of a dependency that keeps failing, and only auto-retry writes that carry an idempotency key.

Ask AI for it

Wrap these API calls in a retry helper using exponential backoff with full jitter: delay = random(0, min(maxDelay, baseDelay * 2 ** attempt)) with baseDelay 250ms, maxDelay 20s, and 4 attempts max plus an overall time budget. Retry only the failures this provider documents as transient (typically 408, 429, 502, 503, 504, network errors, and timeouts on idempotent calls); fail fast on 4xx and on 5xx codes that will never succeed on their own, like 501. Honor the 'Retry-After' header when present, log each attempt with the reason and the delay, and send an idempotency key so retried writes cannot duplicate.

You might have meant

retry policyrate limitidempotency keytimeoutcircuit breaker