n8n Error Handling and Retry Workflows: The Complete 2026 Setup
Short answer: n8n error handling has three separate layers and they don't overlap the way people expect. Turn on Retry On Fail in a node's Settings tab for transient errors like API timeouts (max 5 tries, up to 5000ms between them). Wire a global Error Trigger workflow into every production workflow's Settings > Error Workflow dropdown to catch anything that still breaks and alert you. Use Stop And Error to fail on purpose when your own data is wrong, not the API's fault. Skipping all three is why workflows fail at 3am and nobody finds out until the next morning.
Layer 1: Retry On Fail (per-node, for flaky APIs)
Open any node, click into its Settings tab, and toggle on Retry On Fail. Two fields show up: Max Tries, how many times n8n re-runs the node before giving up, capped at 5, and Wait Between Tries (ms), the delay before each attempt, capped at 5000ms. This is the cheapest reliability fix in n8n and the one most people never touch. Use it on HTTP Request nodes, third-party API integrations, and database calls, anything that occasionally times out or gets rate-limited, not on nodes where a failure means your own logic is broken.
One quirk worth knowing before you rely on it: if Retry On Fail is on and the node's On Error setting is one of the Continue options, the Max Tries and Wait Between Tries values get ignored, the node continues on the first failure instead of retrying (documented n8n behavior, issue #10763). Pick one job per node: retry until it works, or continue past failure and handle the bad data separately. Trying to do both from the same node doesn't work.
Layer 2: On Error setting (Stop, Continue, or route the failure)
Every node also has an On Error dropdown with three options: Stop Workflow (the default, one bad item kills the whole run), Continue (passes error data downstream and keeps going), and Continue (using error output) (adds a second output pin on the node, one for success, one for errors, so you can route failures into their own branch). That third option is the one worth building around: process a batch of 200 leads, send the 195 that succeed onward, and route the 5 that errored into a Set node that logs them to a sheet for manual follow-up instead of losing the whole run over five bad rows.
Layer 3: the Error Trigger workflow (catches everything else)
The Error Trigger node is the foundation of n8n's global error handling. It needs zero configuration, drop it into a new, separate workflow, then go into each of your production workflows' Settings tab and pick that workflow from the Error Workflow dropdown. One Error Trigger workflow can watch every other workflow you have. When any of them fails outright (after node-level retries are exhausted), n8n automatically fires the Error Trigger with a structured payload: the failed workflow's ID and name, the execution URL, the error message and stack trace, and the last node that ran. From there, wire it into a Slack message or email node so you find out in real time instead of discovering it in the Executions tab three days later.
The one gotcha: Error Trigger only fires on automatic (scheduled, webhook, trigger-based) executions, clicking "Execute Workflow" manually in the editor will not test it. You have to actually break something in production, or intentionally trigger a real failure, to confirm the alert path works before you trust it.
Stop And Error: failing on purpose
Sometimes the API call succeeds but the data it returned is wrong, a required field is empty, a lookup came back with zero results, a number is negative when it should never be. That is not an API failure Retry On Fail can help with; it is your workflow's own logic catching bad data. The Stop And Error node lets you throw a deliberate error with a custom message at that exact point, which then flows into your Error Trigger workflow the same way an API failure would, so your alerting stays centralized even for self-inflicted stops.
What a production-grade setup actually looks like
| Layer | Scope | Use it for |
|---|---|---|
| Retry On Fail | Single node | Transient errors: API timeouts, rate limits (HTTP 429/500/502/503), network blips |
| Continue (using error output) | Single node | Partial failure is acceptable, keep good data, route bad items to their own branch |
| Error Trigger workflow | Global, every workflow | Centralized logging and alerting when something fails outright |
| Stop And Error | Single node, on purpose | Your own data is invalid, fail loudly instead of processing garbage silently |
Practical settings to start from: Max Tries 2-3 (not the max of 5, five attempts against a genuinely dead endpoint just delays the alert), Wait Between Tries at least 1000ms so you are not hammering a struggling API, and only retry on the error codes that are actually transient (429, 500, 502, 503), retrying a 400 or 401 wastes time since the request will fail the same way every time.
The free option (it already is one)
There is no upsell here, Retry On Fail, the On Error selector, the Error Trigger node, and Stop And Error are all core n8n functionality included in Community Edition, whether you are self-hosting or on n8n Cloud's free tier. Nobody needs to buy anything extra to build proper error handling; the only cost is the 20-30 minutes it takes to wire an Error Trigger workflow into your existing automations, which most people skip until the first silent failure costs them something.
Verdict
If you run n8n for anything that matters, lead capture, client automations, billing, and you have not built an Error Trigger workflow yet, that is the highest-leverage 30 minutes you can spend on it this week. Add Retry On Fail to your flakiest API-calling nodes first (the ones that fail once a week, not the ones that never fail), then build one central Error Trigger workflow with a Slack alert and point every production workflow's Error Workflow setting at it. The Template availability currently offers no download or email signup. Related reading: self-hosting guide.
FAQ
How do I retry a failed node in n8n?
Open the node, go to the Settings tab, and turn on Retry On Fail. Set Max Tries (capped at 5) and Wait Between Tries in milliseconds (capped at 5000ms). This re-runs just that node automatically before the workflow gives up, use it on HTTP Request nodes and any third-party API call that occasionally times out or rate-limits.
What is the n8n Error Trigger node and how is it different from Retry On Fail?
Retry On Fail works inside a single node to survive transient blips. The Error Trigger node is the start of a separate workflow that n8n calls automatically whenever any monitored production workflow fails outright, after retries are exhausted, so you can log it, alert yourself on Slack or email, and see the failed execution URL. Set it in each workflow's Settings tab under Error Workflow.
Can I retry an n8n workflow for free?
Yes, Retry On Fail, the On Error node setting, the Error Trigger node, and the Stop And Error node are all built into n8n Community Edition with no license fee, whether you self-host or run n8n Cloud's free tier. There is no paid add-on required for basic error handling. See my n8n review for beginners if you are still deciding whether n8n is the right tool at all.