n8n Error Handling
Make n8n workflow failures routable, visible, and recoverable.
The skill explicitly recommends sanitizing error responses, avoiding stack traces/SQL/tokens, and asking before side-effectful tests. However, its examples involve logging, Slack, email, Data Tables, n8n API credentials, and execution-data retrieval without a systematic least-privilege model, sensitive-data boundary, rollback plan, or retention guidance, so points are deducted. No explicit red-line risk was found.
The two-step error-output setup, failure modes, and read-back verification are concrete, making the happy path plausible from static inspection. Nothing was executed, and the documentation contains an internal ambiguity about using `respondWith: json` together with `JSON.stringify`, with limited version-compatibility and abnormal-input coverage; therefore the score stays below the static ceiling.
Triggers, Webhook/unattended/one-off scenarios, and some non-fit guidance are clearly described. Still, complete input/output contracts, edge-case boundaries, and safeguards against semantic mis-triggering are limited. Chinese-language support is absent, and reachability of n8n-mcp plus Slack/email dependencies from mainland China is not established, so points are deducted.
The documentation is layered and includes navigation, anti-patterns, checklists, prerequisites, an MIT license, and a 1.0.0 version. It lacks a meaningful changelog, explicit maintenance ownership, and a clear update path, while cross-file dependency and version-drift governance remain incomplete, so points are deducted.
The core task—configuring error outputs, retries, API status codes, and Error Workflows—has directly reusable operational shapes and could complete the main work. Static review provides no verified representative output or execution result, and some examples need substantial manual validation, so effectiveness is capped at 7 under the calibration rule.
The material includes JSON/JavaScript examples, verification procedures, and stated categories of authoritative sources, providing limited auditability. It lacks independently checkable third-party evidence, committed tests, or CI coverage, and no reproduction was performed in this review, so the score remains below the static ceiling.
- No n8n workflow or MCP operation was executed; validate `onError`, `main[1]`, retry limits, and actual HTTP responses in an isolated environment before activation.
- Check the `Respond to Webhook` combination of `respondWith` and `JSON.stringify` to avoid double encoding or version-specific behavior.
- Do not default to sending full errors, execution inputs, or credential-related fields to Slack, email, or external logs; confirm permissions, redaction, retention, and fallback handling first.
- The core depends on n8n-mcp and optional notification services; mainland-China reachability and alternative notification channels require separate confirmation.
What does this skill do, and when should you use it?
This is one focused Agent Skill from the n8n-skills repository, designed for error handling in webhook, API, and unattended n8n workflows. It covers per-node error outputs, network retries, workflow-level Error Trigger workflows, and structured 4xx/5xx responses. Its central warning is that onError and the corresponding error-output connection must both be configured to prevent silent failure. It is a good fit for users building n8n workflows with n8n-mcp; assigning an Error Workflow still requires the n8n UI.
Guides an agent to configure onError, retryOnFail, maxTries, and waitBetweenTries through n8n-mcp; connect error outputs with sourceIndex: 1; build Error Trigger → capture → notify workflows; and create Respond to Webhook responses with explicit status codes and an {error,message} envelope. It also explains how to inspect configurations with n8n_get_workflow and use validate_workflow, n8n_validate_workflow, n8n_autofix_workflow, n8n_test_workflow, and n8n_executions for validation, repair, testing, and failure inspection.
- An n8n developer needs a webhook or API workflow to return controlled success and failure responses through Respond to Webhook.
- An automation engineer needs retries, alerts, and an Error Trigger safety net for cron, queue, or agent-tool workflows running unattended.
- A user is diagnosing workflows that fail silently, leave callers waiting, or return HTTP 200 with an error body.
- An API builder needs to distinguish validation, authorization, rate-limit, upstream, timeout, and internal failures with appropriate status codes.
What are this skill's strengths and limitations?
- Covers node-level routing, retries, and workflow-level fallback as one failure-handling strategy.
- Clearly identifies the common silent-failure trap where onError is configured but main[1] is unwired.
- Maps failure causes to specific 4xx/5xx responses and emphasizes sanitizing internal details.
- Provides concrete n8n-mcp fields, connection patterns, and verification steps.
- It focuses on n8n error handling rather than complete workflow architecture, node discovery, or deployment.
- Assigning an Error Workflow cannot be done through the community MCP and must be configured in the n8n UI.
- The source provides no independent test results across n8n versions, platforms, or production projects.
- Retries apply to any error; maxTries is capped at 5 and waitBetweenTries at 5000 ms, with no per-status-code filter.
How do you install this skill?
The Skill is located at skills/n8n-error-handling/SKILL.md in the repository. To install the full collection in Claude Code, run /plugin install czlonkowski/n8n-skills. Alternatively, clone the repository and copy n8n-skills/skills/n8n-error-handling into ~/.claude/skills/ after running git clone https://github.com/czlonkowski/n8n-skills.git. The n8n-mcp MCP server must also be installed and configured. The README does not document a separate single-skill plugin command.
How do you use this skill?
With the Skill loaded, use a concrete prompt such as: "Configure error outputs, retries, and 4xx/5xx responses for my n8n webhook workflow" or "My n8n workflow fails silently; check onError and the main[1] connection." For unattended workflows, also request an Error Trigger workflow and assign it through n8n UI: Workflow Settings → Error Workflow.
How does this skill compare with similar options?
Compared with n8n's default stopWorkflow behavior, this Skill recommends explicit routing, notification, and recovery for workflows exposed to callers or running unattended. It also distinguishes per-node error outputs from an Error Trigger catch-all for anticipated versus escaped failures.