Webhook Retry Backoff Calculator
Build an exponential backoff retry schedule for webhooks or API calls, with per-attempt delays, a max cap and total elapsed time.
How it works
Delay(n) = min(base × multiplier^(n−1), cap) · Total = sum of all delays · Add jitter in practice to avoid thundering herds
Exponential backoff spaces out retries by an ever-growing delay so a struggling server gets breathing room instead of a wall of immediate retries. The delay doubles (or scales by your multiplier) each attempt until it hits a cap, which prevents waits from ballooning to hours. In production you also add jitter — a random fraction of each delay — so that many clients failing at once do not retry in perfect lockstep and re-overload the recovering service.
Worked example
With a 1 s base, 2× multiplier and a 300 s cap over 6 retries, the delays are 1, 2, 4, 8, 16 and 32 seconds. They sum to 63 seconds of total waiting before the final attempt — none hit the cap yet.
Frequently asked questions
Why add jitter to backoff?
Without jitter, thousands of clients that failed at the same moment retry at the same moments, hammering the recovering server in synchronised waves. Randomising each delay spreads the load out and lets the service recover.
What is a sensible retry cap?
It depends on how time-sensitive the event is. For webhooks, many providers retry with backoff for hours or days (capping individual delays at minutes) before marking delivery failed. For interactive API calls, seconds to a minute is more appropriate.
Should every error be retried?
No. Retry transient failures — timeouts, 429 rate limits and 5xx server errors — but not 4xx client errors like 400 or 401, which will fail identically no matter how many times you try. Retrying those just wastes resources.
Related calculators
This calculator is for educational purposes. Double-check important results before acting on them.