n8n Error Handling

Operational boundaries

Discover actual n8n tool schemas and node versions: this tree bundles documents, not an MCP server. Drafting does not authorize changing or activating production workflows, sending alerts or replaying writes. Retry only operations proven idempotent or protected by durable deduplication; ambiguous timeouts may have committed. An Error Trigger is not a process-crash/OOM availability guarantee: use independent platform monitoring. It does not fire for manual editor executions. Node error output positions depend on node output layout; verify rather than assuming index 1 for multi-output nodes. Use structured error codes rather than regex matches on untrusted text to decide status or retries.

When to Use

Use this skill for unattended workflows, webhook/API response contracts, retry design, error outputs, Error Trigger workflows, alerting, or any path where failure must be visible and recoverable.

Make retries bounded and idempotent, especially for sends, payments, and writes. Redact credentials, personal data, request bodies, and stack details from caller-facing responses and alerts; expose only the minimum diagnostic context required.

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: