What is exponential backoff?
Quick answer
Exponential backoff is a way of retrying a failed request where the wait grows each time, usually doubling: try, wait 1 second, try, wait 2, then 4, then 8. It gives a busy server or an app's rate limit time to recover, instead of hitting it again at once and failing the same way.
Last updated
Take the free module →Module 7 of the free n8n Jump Start course, about 10 minutes. No account needed.
Updated · By Robert Breen
Why it matters for a small business
Many failures fix themselves if you wait: a server under load, a short outage, or a rate limit that answers with a 429 "too many requests" error. Retrying instantly often just adds to the load. Waiting longer each time gives the app breathing room and is what most API documentation asks for.
It matters most for workflows that run unattended, such as a 6am price update. A single failure at 6:00 that recovers at 6:01 should not leave you on stale data all day. Retries with growing waits catch those short problems without a person.
Where you'll use it: n8n's Retry On Fail setting waits the same time between each try, so for true backoff you build it with a loop and a Wait node whose time grows, or rely on an app's own retry behavior. In the HTTP Request node, read the API's docs for a Retry-After header, which says how long to wait.
In a real lesson: Get Alerted When an n8n Automation Fails, and Let It Retry by Itself
In the free n8n error handling lesson, Maple Lane Florist's supplier server is busy at 6am. You turn on Retry On Fail, leave Max. Tries at 3, and set Wait Between Tries (ms) to 5000, five seconds, the most that field allows.
That is a fixed wait, not exponential backoff. For an API that is often overloaded for a minute or more, a workflow could retry after 5, then 10, then 20 seconds using a Wait node in a loop, and still email the owner through the error output if the last try fails.
Try this lesson free or read the step-by-step guide.
Common confusions
Exponential backoff vs fixed retry
A fixed retry waits the same time every try. Backoff waits longer each time, which suits outages that last more than a few seconds.
Backoff vs rate limiting
A rate limit is the app's rule. Backoff is how your workflow behaves when it hits that rule.
Tips
- Cap the number of tries, so a real outage ends in an alert, not an endless loop.
- Add a little random extra time, called jitter, if many workflows retry the same app.
- Only retry steps that are safe to repeat.
Related terms
More n8n and automation terms
Where you use it: free lessons
- Get Alerted When an n8n Automation Fails, and Let It Retry by Itself (n8n, 10 min)
- n8n: Call Any API with the HTTP Request Node (n8n, 9 min)
Frequently asked questions
- Does n8n have built-in exponential backoff?
- Retry On Fail uses a fixed wait between tries. Build growing waits with a loop and a Wait node if you need them.
- How many retries should I allow?
- Three to five is common. After that, send an alert so a person can check.