Skip to content
ENExplore Calculators

Webhook Retry Calculator

Size an exponential backoff schedule with jitter: total retry window, delivery probability and the retry storm your consumer will see.

About Webhook Retry Calculator

Exponential backoff grows geometrically until it hits the cap and then becomes linear, so the total window is a geometric sum plus a flat tail. Full jitter randomises each delay uniformly, which halves the expected wait and — more importantly — spreads a synchronised retry storm out over the delay window instead of concentrating it in one second. A retry schedule without jitter is a self-inflicted denial of service on the consumer: every failed delivery retries in lockstep, so the recovering endpoint is knocked over again by your own traffic.

Formulas

Webhook Retry

With base delay b, multiplier m and cap c, the delays are min(b·m^i, c); their sum is the geometric series b(m^k − 1)/(m − 1) over the k attempts before the cap, plus (attempts − k) × c afterwards.

b
Base delay before the first retry
m
Backoff multiplier
c
Per-attempt delay cap
k
Attempts made before the cap is reached

Jitter and delivery

Full jitter halves the expected delay, so the expected window is the nominal window × (1 − jitter ÷ 2); cumulative delivery probability = 1 − (1 − p)^attempts.

jitter
Randomised share of each delay
p
Per-attempt success probability

Worked example

With the default values below, Webhook Retry Calculator returns Total Retry Window of 0.35. Change any input above and every figure here is recalculated in your browser.

Inputs used

Base delay before the first retryaccepts 0.1–3,600 seconds
5 seconds
Backoff multiplieraccepts 1–10 ×
2 ×
Maximum attemptsaccepts 1–50 attempts
8 attempts
Delay cap per attemptaccepts 1–604,800 seconds
3,600 seconds
Full-jitter range applied to each delayaccepts 0–100 %
100 %
Per-attempt delivery successaccepts 0.1–100 %
60 %
Events failing in the same instantaccepts 1–100,000,000 events
5,000 events

Results

Total Retry Window
0.35 hours
Expected Window With Jitter
0.18 hours
Delay Before the Final Attempt
640.0 seconds
Cumulative Delivery Probability
99.935%
Peak Retry Rate With Jitter
1,000.0 events/s
Assessment
Schedule is well balanced

Step by step

  1. 1Values used
  2. 2Webhook Retry
  3. 3Jitter and delivery
  4. 4Total Retry Window= 0.35 hours
  5. 5Expected Window With Jitter= 0.18 hours
  6. 6Delay Before the Final Attempt= 640.0 seconds
  7. 7Cumulative Delivery Probability= 99.935
  8. 8Peak Retry Rate With Jitter= 1,000.0 events/s
  9. 9Assessment= Schedule is well balanced

Assumptions and limits

  • The result is derived only from the 7 inputs listed above. Anything not among them is not part of the calculation.
  • In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
  • Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is Webhook Retry calculated?

With base delay b, multiplier m and cap c, the delays are min(b·m^i, c); their sum is the geometric series b(m^k − 1)/(m − 1) over the k attempts before the cap, plus (attempts − k) × c afterwards. Exponential backoff grows geometrically until it hits the cap and then becomes linear, so the total window is a geometric sum plus a flat tail. Full jitter randomises each delay uniformly, which halves the expected wait and — more importantly — spreads a synchronised retry storm out over the delay window instead of concentrating it in one second.

Why does Webhook Retry matter?

A retry schedule without jitter is a self-inflicted denial of service on the consumer: every failed delivery retries in lockstep, so the recovering endpoint is knocked over again by your own traffic.

What values do I need to enter?

This calculator takes 7 inputs: Base delay before the first retry, Backoff multiplier, Maximum attempts, Delay cap per attempt, Full-jitter range applied to each delay, Per-attempt delivery success, Events failing in the same instant. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

How many attempts should a webhook get?

Enough to ride out a normal outage and no more — typically six to ten attempts spread over a few hours to a day, then a dead-letter queue with an operator-visible replay. Retrying for a week hides the failure, ties up delivery workers and eventually replays events the consumer no longer has context for.

Related Calculators

Webhook Retry Calculator – Calculate Total Retry Window