What is exponential backoff?
Exponential backoff is a retry schedule where each retry waits exponentially longer than the previous one. A typical schedule: 30s, 1m, 5m, 15m, 1h, 4h, 12h, 24h. Early retries catch transient blips; later retries catch longer outages without hammering the recovering system.
The opposite — constant-interval retries (every minute, forever) — is the most common production mistake. It overloads systems that are trying to recover and never adapts to longer outages.
Why exponential backoff is the right default
Three reasons it beats both constant and linear schedules:
- Self-healing. If the destination has a 5-second blip, the first retry catches it. If it's a 5-hour outage, later retries catch it too — the schedule scales naturally.
- Less load on recovering systems. A destination coming back from an outage faces a thundering herd of retries. Exponential backoff spreads them out.
- Bounded total time. With reasonable parameters (initial 30s, multiplier 2, max ~24h), the total retry budget is finite — you can predict when a delivery will move to the DLQ.
Adding jitter
Pure exponential backoff has a synchronization problem: if many deliveries fail at the same time (an upstream incident), they all retry at the same scheduled times — recreating the thundering herd. The fix is jitter — randomize the wait by ±20% or so, spreading out the retries.
Most production retry libraries default to "exponential backoff with jitter" for this reason. The variance smooths the load curve.
For the broader retry context: Webhook DLQs: design and recovery patterns.
Frequently asked questions
Why is exponential backoff better than retrying at a constant interval?
Three reasons: it self-heals across both a five-second blip and a five-hour outage without tuning, it puts less load on a system that is trying to recover, and with sane parameters the total retry budget is finite so you can predict when a delivery moves to the DLQ.
What is jitter and why add it?
Randomizing each wait by roughly 20% either way. Without it, deliveries that failed together during an upstream incident all retry at the same scheduled moments and recreate the thundering herd the backoff was meant to avoid.
What is Hooksbase?
Hooksbase is event infrastructure for AI agents. It ingests events over four channels — HTTP, email, HTML form, and scheduled cron — verifies them, routes them by rule, runs versioned Automations in the event path, and delivers them to HTTP and cloud destinations (AWS SQS, AWS EventBridge, GCP Pub/Sub, and S3-compatible storage) with retries, strict ordering, Standard Webhooks-compatible signing, deterministic replay, and a dead-letter path. It is a hosted service, runs on Cloudflare Workers, is operated at hooksbase.com, and is not affiliated with — and shares no code or ownership with — other similarly named webhook, hook, or tunnelling tools.
Related terms
- Retry
Re-attempting a failed delivery on a backoff schedule until it succeeds or hits a retry budget.
Read - Idempotency
A property where performing an operation multiple times produces the same result as performing it once.
Read - DLQ (Dead-Letter Queue)
A holding area for messages that failed terminally so they can be inspected and recovered.
Read - Fan-out
Delivering one event to multiple consumers in parallel.
Read