How do you design a safe webhook retry policy?
Webhooks can fail due to transient outages or network issues on the receiving end, which makes retry logic essential. This tool takes your expected per-request failure rate and retry count to calculate the probability that every attempt fails, and shows the wait time for each retry under an exponential backoff scheme.
The final failure rate is calculated as (per-request failure rate)^(retries + 1). For example, with a 10% failure rate and 4 retries, the probability that all 5 attempts fail drops to 0.1^5 = 0.001% — extremely low. More retries raise your success rate, but the total wait time also grows exponentially with the backoff multiplier, so there's a real tradeoff.
The backoff multiplier exists because if every client retries at the exact same moment during an outage, it only piles more load onto the struggling server. Spacing out retries with a growing delay gives the server room to recover — that's the core of a resilient design.
Frequently Asked Questions
Success rate goes up, but so does the total wait time until the last retry. For time-sensitive webhooks, capping retries at 3-5 is common practice.
If every client retries at the same instant during an outage, it only adds more load to the struggling server. A growing backoff spreads out retries and gives the server time to recover.
Yes. Real failure rates vary by time of day, traffic, and outage type, so it's best to tune your inputs using historical log data.