N8n Error Handling
Wire n8n error handling so failures are loud, structured, and recoverable.
Install
npx skills add czlonkowski/n8n-mcp --skill n8n-error-handling -g -a claude-code -y- Repository
- czlonkowski/n8n-mcp23.2k
- Category
- Engineering
- Updated
- 8d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Wire n8n error handling so failures are loud, structured, and recoverable. Use when building any webhook/API workflow, a scheduled or unattended workflow, or any path where a silent failure would drop user-visible work, and whenever the user mentions error handling, onError, continueErrorOutput, error branches/outputs, retries, retryOnFail, Respond to Webhook status codes, 4xx/5xx, Error Trigger, or "my workflow fails silently". Covers per-node error outputs and wiring, retry/self-healing, error-trigger workflows, and 4xx/5xx response shapes.
n8n Error Handling
By default, when an n8n node throws, the whole workflow halts. For an interactive run you're watching, that's fine, you see the red node and fix it. For anything unattended (a webhook API, a cron job, a queue worker, an agent tool), it's the wrong default: the caller gets a timeout or an empty 500, the operator gets no alert, and the symptom is "the integration just stopped working" with no log and no clue.
This skill is about making failures loud, structured, and recoverable, and, best case, self-healing so transient blips never reach a human at all.
The two ideas that prevent most silent failures:
- Per-node error outputs, a node's failure routes down a second output you control, instead of killing the run.
- A workflow-level error workflow, a catch-all that fires for anything that escapes per-node handling (timeouts, crashes between nodes, unwired failures).
When you actually need this
| Workflow shape | Error handling posture |
|---|---|
Webhook / API (anything with Respond to Webhook) | Required. Every fallible node's error output wired; status code matches cause. |
| Scheduled / cron / queue worker / agent tool (unattended) | Required. A workflow-level error workflow, plus retryOnFail on network nodes. |
| Internal one-off you run and watch yourself | Optional. Default onError: "stopWorkflow" is fine, you'll see the red node and re-run. |
The dividing line: if anyone other than you sees the output, a downstream system, an end user, an on-call engineer, the failure has to be handled, not swallowed. If you're the only watcher and the cost of failure is "I notice and re-run", looser is fine.
The #1 silent trap: per-node error output is a TWO-step setup
This is the single most common way an n8n workflow "handles" errors while actually swallowing them. Routing a node's failure to a handler takes two changes, and doing only one looks complete but misbehaves:
