Retries and passing failures
🎯You'll be able to
Tell passing failures from lasting ones and set retries with backoff only where they help.
🏠The everyday picture
If a call doesn't connect, you try again in a minute. If the number has been disconnected, calling again every minute won't help; you need a different number.
📘What it really is
- Failures come in two kinds:
- Passing (transient): a timeout, "429 Too Many Requests", "503 Service Unavailable". Trying again later often works.
- Lasting (permanent): "401 Unauthorized", "404 Not Found", "400 Bad Request" with invalid data. Retrying gives the same error; a person or a fix is needed.
-
n8n nodes have a Retry On Fail setting with a number of tries and a wait between them. Use it on steps that call outside services.
-
Backoff: wait longer between each try (for example 5 s, 20 s, 60 s), so a struggling service gets time to recover.
-
Rate limits: many APIs allow only so many calls per minute. Batch calls and add a short wait instead of sending hundreds at once.
-
After the last retry, the failure should go to the error path (Lesson 2), not disappear.
📝A worked example
The Sharma Textiles payment workflow calls the accounts app's API, which sometimes answers "503" during its nightly backup at 2 am.
| Error | Kind | Handling |
|---|---|---|
| 503 Service Unavailable | Passing | Retry 3 times, waiting 30 s, 2 min, 5 min |
| 429 Too Many Requests | Passing | Retry after the wait the API suggests |
| 401 Unauthorized | Lasting | No retry; alert: credentials need attention |
| 400 Bad Request | Lasting | No retry; alert with the input data |
Over a month, 11 runs hit a 503. All 11 succeeded on a retry, and none needed a person.
🌍Where it's used
- Payment and accounts integrations where outside services have short outages.
- Bulk sends such as campaigns, which meet rate limits.
- APIs with maintenance windows.
📝Case scenario
A campaign workflow sends 800 WhatsApp messages and about 200 fail with "429 Too Many Requests". Retrying immediately makes it worse. You split the list into batches of 50 with a pause between batches, and add Retry On Fail with a longer wait. The next run sends all 800 without a rate-limit error.
🖱️Try it
For each external call in your order workflow, write down which errors are passing and which are lasting. Turn on Retry On Fail with sensible waits for the passing ones, and test by pointing one call at a URL that times out.
⚠️Common mistakes
- Retrying everything. Sign: an expired key is tried 50 times. Fix: retry 429, 5xx and timeouts; alert on 401, 403, 404 and 400.
- Retrying instantly. Sign: retries hit the same rate limit. Fix: wait longer between each attempt, and respect
Retry-After.
🛠️For your project
Project 1 test 7 sends two 503 replies before the accounts service recovers; test 8 sends 401 every time. Your workflow must treat them differently.
✅Quick check
Is "401 Unauthorized" worth retrying automatically?
Show the answer
No. It's a lasting error: the credentials need attention, so it should alert a person.
What is backoff?
Show the answer
Waiting longer between each retry, so a struggling service has time to recover.