Exponential backoff / retry calculator
Exponential: wait_i = min(cap, base × 2^i) seconds. Jitter is not applied.
Retry failed API and webhook steps without hammering them
Agentic workflows call APIs, webhooks, and AI models that sometimes time out or hit a rate limit. Retrying immediately in a tight loop makes things worse. This retry / backoff calculator shows how long each retry will wait with exponential backoff and a cap, and how long the step can take before it gives up.
How to use the retry / backoff calculator
Enter the base delay in seconds, the number of retries, and the cap — the longest single wait you’ll allow. The list shows the wait before each retry, and the total shows the worst-case time spent waiting if every retry fails.
Your retry waits
- 1s
- 2s
- 4s
- 8s
- 16s
31s total wait
What your result means
The total is the waiting time only — it does not include how long each attempt itself takes, and it assumes no jitter. If the total is longer than the step can afford (for example, while a customer is waiting for a reply), lower the retries or the cap and plan a fallback.
FAQ
What is exponential backoff?
Exponential backoff is a retry strategy where each retry waits longer than the one before — here the wait doubles each time. When an API, webhook, or model call fails, the workflow gives the other service time to recover instead of retrying over and over straight away.
How does this retry / backoff calculator work?
Each wait is min(cap, base × 2^i) seconds, where i counts retries from 0. The calculator lists the wait before each retry and adds them up for the total. With the defaults — a 1-second base, 5 retries, and a 30-second cap — the waits are 1, 2, 4, 8, and 16 seconds, for 31 seconds in total.
Why set a cap on the wait?
Without a cap, the doubling quickly produces very long waits, so a single failing step can stall the whole workflow. The cap sets the longest the workflow will wait between retries; once the doubled wait reaches it, every later retry waits the cap.
Does the calculator include jitter?
No. Jitter adds a random amount to each wait so that many runs retrying at once don’t all hit the service at the same moment. It is common to add it in the workflow itself; with jitter, the real total wait will differ from the figure shown here.
What should an agentic workflow do when retries run out?
Send the task to a fallback instead of failing silently: alert a person, queue it to try later, or mark it failed with the error logged. Only retry errors that can clear on their own, such as timeouts or rate limits, and make sure the step is safe to repeat so a retry can’t send the same message or charge twice.
Need agentic workflows that recover from failures?
GoWith agentic builds add retries, fallbacks, and approval steps where a failed or risky action needs a person. See all free tools, the webhook JSON checker, the HITL gate picker, and the agent vs workflow scorer.
Educational only. Not legal advice and not a substitute for testing the live agent. Retry / backoff calculator runs in your browser — nothing is sent to your CRM unless you copy it yourself.
Related workflow reliability tools
Worked out your retry policy? Book a consult and we’ll help you build your business workflow as an agentic workflow with retries, fallbacks, and human handoff on the steps that fail.