n8n Error Handling

Default n8n node behavior: error → workflow halts → caller gets nothing useful. For unattended workflows (webhook APIs, scheduled jobs, queue workers), that default is wrong. The symptom is "the integration just stopped working" with no log, no message, no clue.

This skill is about handling errors so failures are loud, structured, and recoverable. Or best case scenario, handled in a way where it self heals.

Non-negotiables

For any API-shaped workflow (webhook trigger paired with Respond to Webhook):

1. Every fallible node's error output is wired, and both paths end at a Respond to Webhook. No hanging error branches, or the caller would see a timeout. "Fallible" = HTTP, DB, third-party API, file operation, anything that throws.
2. Status code maps to cause. Caller's fault → 4xx, your fault → 5xx. A 200 default on an error path produces silent failure: caller thinks success, processes empty data.

For any unattended workflow (scheduled, cron, queue-driven, agent tool): 3. Set a workflow-level error workflow. Catches what escapes per-node handling: timeouts, crashes between nodes, errors in unwired nodes. Set it via update_workflow setWorkflowSettings.errorWorkflow (n8n 2.29.0+); the target must be a published workflow containing an active Error Trigger, or the update is rejected. See references/ERROR_WORKFLOWS.md.

Strong defaults