Exponential Backoff
Exponential backoff is an algorithm for limiting retry attempts by increasing the time delay between attempts exponentially. After a failure, the system waits briefly before trying again; after each subsequent failure, the wait roughly doubles. The result is a retry schedule that reacts quickly to short-lived problems without hammering a system that is genuinely down.
In webhook system design, exponential backoff is used to define webhook retry schedules for failed webhook messages. It’s an ideal way to handle failed deliveries because it tries again quickly at first, in case the problem was transient, but does not waste all of its retries in the case that the endpoint is broken for hours.
How the algorithm works
The core idea is a delay that grows as a function of the attempt number, typically delay = base × 2^attempt, capped at some maximum. With a one-second base, the first retry happens after one second, then two, four, eight, sixteen, and so on. A real schedule usually stops after a fixed number of attempts and hands persistent failures off to a dead letter queue for inspection or manual replay.
Production implementations usually add jitter, a small random offset added to each delay. Without jitter, every client that failed at the same moment retries at the same moment too, producing synchronized waves of traffic that can knock over a recovering service. This is known as the thundering herd problem, and jitter spreads those retries out.
Why not retry at a fixed interval?
A fixed interval forces a bad tradeoff. Retry every few seconds and a broken webhook endpoint burns through the entire retry budget in a minute, long before anyone has had a chance to fix it. Retry every hour and a five-second network blip delays an otherwise healthy delivery by an hour. Exponential backoff covers both cases with one schedule: early retries catch transient failures within seconds, while later retries stretch out far enough to give a broken receiver hours to recover.
As a concrete example, Svix retries failed webhook deliveries immediately, then at 5 seconds, 5 minutes, 30 minutes, 2 hours, 5 hours, and twice more at 10-hour intervals, giving receivers more than a day to recover before a message is marked failed.
Where else exponential backoff shows up
The same algorithm appears anywhere transient failure is normal: HTTP clients retrying API requests, message consumers reconnecting to a message broker, TCP congestion control, and job queues rescheduling failed work. If you are implementing it on the receiving side of webhooks, our guide on webhook retry strategies covers schedules, budgets, and the failure modes to plan for.