Retry Delay Calculator
Visualize backoff strategies and see exactly when each retry fires.
| Attempt | Delay | Cumulative | Timestamp |
|---|
Delay Timeline
Designing a retry strategy?
Recuro has configurable retry delays built in. Set your backoff strategy per schedule and we handle the rest.
Strategy Comparison
Side-by-side view using your current settings across all four strategies.
| Attempt | Fixed | Linear | Exponential | Exp + Jitter |
|---|
Why retry strategies matter for background jobs and webhooks
When a background job or webhook delivery fails, the simplest response is to retry immediately. But immediate retries rarely help — if the downstream service is overloaded or temporarily unreachable, hammering it with repeated requests makes things worse. A well-chosen retry strategy gives the failing service time to recover while ensuring your request eventually gets through.
Fixed delay retries at the same interval every time (e.g., every 5 seconds). This is simple but inefficient — it does not adapt to the severity of the failure. Linear backoff increases the delay proportionally with each attempt (5s, 10s, 15s, 20s), giving more breathing room over time. Exponential backoff is the industry standard: delays grow geometrically (1s, 2s, 4s, 8s, 16s), which naturally spaces out retries and reduces load on the failing service.
Adding jitter (randomness) to exponential backoff is critical in distributed systems. Without it, all clients that fail at the same instant will retry at the same instant, creating synchronized bursts of traffic. Jitter randomizes the delay within a range, spreading retries across time and preventing the "thundering herd" problem.
Recuro handles retries automatically for your scheduled HTTP requests. Configure the backoff strategy, max retries, and delay caps from the dashboard — Recuro takes care of execution, retry scheduling, and alerting when attempts are exhausted so you never miss a failed delivery.
Frequently Asked Questions
What is exponential backoff?
Exponential backoff is a retry strategy where the delay between attempts grows exponentially. For example, with a base delay of 1 second and a multiplier of 2, the delays would be 1s, 2s, 4s, 8s, 16s. This prevents overwhelming a struggling service by spacing out retries further and further apart. Most cloud providers and HTTP libraries use exponential backoff as the default retry strategy.
Why add jitter to retry delays?
Without jitter, all clients that fail at the same time will retry at the same time, creating a "thundering herd" that can overload the server again. Jitter adds randomness to each delay so retries spread out over time. This is especially important for distributed systems where hundreds or thousands of clients might hit the same error simultaneously.
What's a good max retry count for webhooks?
For webhooks, 3 to 5 retries with exponential backoff is a common default. Beyond that, repeated failures usually indicate a persistent issue (endpoint down, DNS misconfigured, certificate expired) rather than a transient blip. Many webhook providers use 5 retries over several hours, then mark the delivery as failed and send an alert. The right number depends on your SLA and how critical the delivery is.
⌘Enter to run · ⌘⇧C to copy