Question 1

How do you set up error handling in n8n?

Accepted Answer

Answer across three levels — that structure makes it clear. "Node level. On nodes that talk to external services I set timeout and retry. But retry is meaningful only for transient failures: 429, 5xx, network errors. Retrying a 401 or 400 is pointless — it only delays visibility. Workflow level. I assign an error workflow in Workflow Settings for every production workflow. It is a separate workflow starting with the Error Trigger, built once and attachable to all of them. Logical level. I validate incoming data early and stop with a clear message via Stop And Error when it is not what I expect. Continuing with partial data creates problems that are hard to find later. On top of that I build tolerance for partial failure: if 3 of 100 records fail the whole execution should not stop. I route the failures separately and send a "97 succeeded, 3 failed" report at the end."

Question 2

What should the notification from an error workflow contain?

Accepted Answer

List the content, then add one technical trap — the trap is what shows experience. "The alert should be enough for the reader to know what to do: Which workflow and which node failed The error message The scale of impact — one record or the whole process The execution link — one click to the detail There is a technical trap: the Error Trigger's payload is not always the same. If the failure happened in the main workflow's trigger node, execution{} carries less and a trigger{} object appears — because the workflow never executed. So you cannot assume execution.url is always present; the error workflow must handle both shapes. Also, execution.id and execution.url require the execution to be saved in the database. In a configuration that does not store execution data those fields are absent — worth accounting for when you build it."

Question 3

What is the difference between a workflow that merely works and one you can rely on?

Accepted Answer

This is a broad question — answer with concrete criteria. "A workflow that works produces the right result in the expected situation. A reliable one behaves correctly in unexpected situations too. I measure the difference on five criteria: 1. Is failure visible? Is there an error workflow, or does nobody find out when it breaks? 2. Is re-running safe? Does a second run create duplicates? Are the writes upserts? 3. Does it tolerate partial failure? Does one bad record stop the other 99? 4. Is data preserved? If it is down for an hour, do that hour's events come back? Is there a cursor? 5. Are edge cases considered? Empty responses, unexpected field types, null values — are they checked? There is one more criterion: can anyone else understand it? Are the node names meaningful, is complex logic explained in a sticky note? A workflow only one person understands is unreliable the moment that person takes leave."

Situation	The right behaviour
3 of 100 records fail	Continue-on-error at node level — route failures down a separate path and report at the end
The API is temporarily unavailable	Node-level retry with an interval between attempts
The credential has expired	Do not retry — alert immediately; this needs a person
The incoming data is not in the expected shape	Validate early with an IF; stop with a clear message using Stop And Error
The whole process has stopped	Immediate alert from the error workflow: which workflow, which node, the execution link

Error handling and the error workflow

📚 Sources and documentation