Retry Calculator
Visualize retry timing for exponential backoff, linear, and fixed strategies. Plan your webhook retry configuration with jitter support.
Configuration
On
Total Retries
8
Total Time Window
4m 15s
3m 11s – 5m 19s
Last Retry Delay
2m 8s
Strategy
Exponential
+jitter
Retry Timeline
t=0
Initial request
1s
#1
3s
#2
7s
#3
15s
#4
31s
#5
1m 3s
#6
2m 7s
#7
4m 15s
#8
Attempt Details
| # | Delay | Cumulative | Window |
|---|---|---|---|
| 0 | — | 0s | Initial request |
| 1 | 1s750ms – 1.3s | 1s | 1s after start |
| 2 | 2s1.5s – 2.5s | 3s | 3s after start |
| 3 | 4s3s – 5s | 7s | 7s after start |
| 4 | 8s6s – 10s | 15s | 15s after start |
| 5 | 16s12s – 20s | 31s | 31s after start |
| 6 | 32s24s – 40s | 1m 3s | 1m 3s after start |
| 7 | 1m 4s48s – 1m 20s | 2m 7s | 2m 7s after start |
| 8 | 2m 8s1m 36s – 2m 40s | 4m 15s | 4m 15s after start |
Recovery Insight
If your endpoint goes down and recovers within a given window, here is how many retry attempts will have been made:
Recovers in 30s
4 / 8
50% used
Recovers in 1m
5 / 8
63% used
Recovers in 5m
8 / 8
100% used
How Exponential Backoff Works
- The first retry fires after the initial delay
- Each subsequent delay is multiplied by the backoff multiplier
- Delays are capped at the max delay to prevent runaway waits
- Jitter adds randomness to prevent thundering herd problems
- After max retries, the delivery is marked as failed
Choosing the Right Strategy
- Exponential — Best for most webhook use cases. Gives the endpoint time to recover without overwhelming it.
- Linear / Fixed — Good for time-sensitive deliveries where you want predictable retry spacing.
- Aggressive — Use when low latency matters more than endpoint protection, such as payment callbacks.
- Conservative — Use for non-urgent events where you can afford to wait hours or days for recovery.
Want more? Try automatic retry management in Hookbase
Get started free with no credit card required.