# n8n Error Handling: How to Stop Workflows from Silently Failing To stop an n8n workflow from silently failing, you need to configure three layers of defense: enable **continueOnFail** on individual nodes to let the workflow proceed past errors, add an **Error Trigger** node to catch and log failures, and set **retry on fail** for transient issues like network timeouts. Together, these settings ensure every failure is either recovered automatically or surfaced visibly instead of disappearing into the void. **n8n error handling is the combination of node-level settings and workflow-level triggers that intercept, log, and optionally recover from execution failures that would otherwise terminate your automation silently.** Most workflow failures in n8n happen in production because the builder tested the happy path but never simulated what happens when an API returns a 500 error, a webhook times out, or a database connection drops. This guide shows you how to trap every failure mode. ## What you need | Tool | Plan/Price | Why you need it | |------|-----------|-----------------| | n8n instance | Self-hosted (free) or Cloud (starts ~$20/month) | The workflow automation platform where you'll configure error handling | | A workflow with at least one HTTP or external service node | Free | To test error scenarios realistically | | Access to workflow settings | Included | Where you'll configure retry behavior and static data | | Error logging destination | Free (n8n internal) or external service | To receive and store error notifications | ## 1. Enable continueOnFail on fragile nodes The first line of defense is preventing a single node failure from killing your entire workflow. Open your workflow and click on any node that calls an external service—HTTP Request, Webhook response, database query, or API call. In the right sidebar, scroll to **Settings** and find the toggle labeled **Continue on Fail**. Enable it. This checkbox does exactly what it says: if this node throws an error, n8n will pass the error object downstream instead of halting execution. The next node receives an item with an `error` property containing the failure details. **When to use it:** Enable continueOnFail on any node where failure is a *possible* outcome you want to handle, not a showstopper. Examples include: - HTTP requests to third-party APIs that might be down - Database lookups for records that might not exist - File operations where the file might be missing **When NOT to use it:** Don't enable it on nodes where failure means your data is corrupted or incomplete. If a payment processing node fails, you probably want the workflow to stop, not continue with bad data. To check if a node failed when continueOnFail is enabled, add an IF node immediately after it with this expression: ```javascript {{ $json.error !== undefined }} ``` Route the "true" branch to your error handling logic (send a Slack message, write to a log, etc.) and the "false" branch to your normal success path. ## 2. Add an Error Trigger to catch everything else The Error Trigger node is a global safety net. When any node in any workflow fails and doesn't have continueOnFail enabled, n8n can fire a separate error-handling workflow. Create a new workflow named "Error Handler" or similar. Add the **Error Trigger** node as the first node. In its settings, choose whether it should trigger on: - **All workflows** (recommended for a centralized error handler) - **Specific workflows** (if you want different handling for different automation types) After the Error Trigger, add nodes to process the failure. Common patterns: **Minimal viable error handler:** ``` Error Trigger → Send Email (with error details) ``` **Production-grade handler:** ``` Error Trigger → Set (extract workflow name, node name, error message) → IF (filter by severity or workflow type) → Send Slack notification → HTTP Request (post to logging service like Sentry or Datadog) → Spreadsheet (append to error log in Google Sheets) ``` The Error Trigger output contains these critical fields: - `execution.id`: The unique ID of the failed execution - `execution.workflowData.name`: Which workflow failed - `execution.error.node.name`: Which node threw the error - `execution.error.message`: The actual error text - `execution.data.resultData.lastNodeExecuted`: The last successful node Use expressions to extract these into a readable message: ``` Workflow "{{ $json.execution.workflowData.name }}" failed at node "{{ $json.execution.error.node.name }}" Error: {{ $json.execution.error.message }} Execution ID: {{ $json.execution.id }} ``` **Critical gotcha:** The Error Trigger only fires for *unhandled* errors. If a node has continueOnFail enabled, the error is considered "handled" and won't trigger this workflow. This is by design—you want errors you've explicitly chosen to continue past to be handled inline, not globally. ## 3. Configure retry on fail for transient errors Many failures are temporary: a network hiccup, a rate limit that clears in 30 seconds, a service restart. For these, you want automatic retry with backoff, not immediate failure. Click on a node, scroll to **Settings**, and expand **Retry On Fail**. You'll see: - **Enable retry:** Toggle this on - **Maximum retries:** How many times to retry (start with 3) - **Wait between tries (ms):** Delay between attempts (start with 2000 for 2 seconds) For exponential backoff, you can't configure it directly in the UI, but you can chain multiple retry attempts with increasing delays by using a combination of workflow settings. **When to enable retry:** - HTTP requests (network transients) - Database connections (connection pool exhaustion) - File system operations (locked files) - Any external API with known intermittent issues **When NOT to enable retry:** - Operations with side effects (sending emails, processing payments) - Errors that are clearly permanent (authentication failed, resource not found) A nuanced approach: enable retry on the node, but set continueOnFail as well. Then check after the retries have exhausted: ```javascript {{ $json.error !== undefined && $json.error.name === "NodeApiError" }} ``` This gives you automatic recovery for transients, but still lets you handle permanent failures gracefully. ## 4. Use workflow static data to track failure counts For sophisticated error handling—like "only alert me if this fails 5 times in a row"—you need to track failure state across executions. That's where workflow static data comes in. Open your workflow settings (click the three dots menu at the top), select **Settings**, and scroll to **Workflow Static Data**. This is a JSON object that persists across executions and can be read and written by nodes. Initialize it with: ```json { "errorCount": 0, "lastError": null, "consecutiveFailures": 0 } ``` In your error handling branch (after an IF node that detected a failure), add a **Set** node with these settings in the JSON view: ```json { "errorCount": "={{ $workflow.staticData.errorCount + 1 }}", "lastError": "={{ $json.error.message }}", "consecutiveFailures": "={{ $workflow.staticData.consecutiveFailures + 1 }}" } ``` Then add a **Function** node to write back to static data: ```javascript // Get current static data const staticData = $workflow.staticData; // Update counts staticData.errorCount = $input.first().json.errorCount; staticData.lastError = $input.first().json.lastError; staticData.consecutiveFailures = $input.first().json.consecutiveFailures; return $input.all(); ``` In your success path (after the IF node's "false" branch where no error occurred), reset the consecutive failure count: ```javascript $workflow.staticData.consecutiveFailures = 0; return $input.all(); ``` Now add an IF node after updating the error counts: ```javascript {{ $workflow.staticData.consecutiveFailures >= 5 }} ``` Only when this evaluates true do you send the urgent alert. This prevents notification spam from transient issues. ## 5. Test your n8n error handling configuration You've configured the safety nets, now deliberately break things to verify they work. Add an **HTTP Request** node pointing to `https://httpstat.us/500` which always returns a 500 error. Configure your error handling around it. Execute manually and verify: 1. With continueOnFail disabled, the workflow stops and your Error Trigger workflow fires 2. With continueOnFail enabled, the error object flows to the next node 3. With retry enabled, you see multiple attempts in the execution log before failing Check the execution list (left sidebar, "Executions") and click into failed executions. You should see: - Red X on the failed node - Error message in the node output - Full stack trace if you expand details If your Error Trigger workflow fired, open it and verify the execution contains the error details from the original workflow. Test your static data tracking by running the workflow 5 times manually, letting it fail each time. On the 5th failure, your alert should fire. Then make it succeed once and verify the consecutive failure count resets. ## 6. Set up structured error responses When continueOnFail is enabled, the error object structure looks like this: ```json { "error": { "message": "404 - Not Found", "name": "NodeApiError", "description": "The requested resource was not found", "httpCode": "404", "cause": {...} } } ``` In your error-handling IF branches, extract and normalize this data with a Set node: ```json { "errorOccurred": true, "errorType": "={{ $json.error.name }}", "errorMessage": "={{ $json.error.message }}", "errorHttpCode": "={{ $json.error.httpCode || 'N/A' }}", "nodePosition": "={{ $node.name }}", "timestamp": "={{ $now.toISO() }}" } ``` This structured format makes it easy to: - Filter errors by type in downstream nodes - Log to external systems with consistent fields - Build dashboards that parse error patterns ## Understanding the n8n error handling hierarchy The three mechanisms work together in a specific order: **Level 1: Retry on Fail** attempts to recover automatically before considering the node failed. **Level 2: Continue on Fail** determines whether a node failure stops the workflow or passes an error object downstream. **Level 3: Error Trigger** catches any unhandled errors (where continueOnFail was disabled or not present) and routes them to a separate workflow. Your strategy should be: - Enable **retry on fail** for nodes with transient failures (network, rate limits) - Enable **continueOnFail** for nodes where you want inline error handling - Always have an **Error Trigger** workflow as the last resort for unexpected failures ## What could go wrong **Problem:** Error Trigger workflow doesn't fire even though a node failed **Symptom:** The main workflow shows as failed, but the error handler never executed **Fix:** Check if the failed node has continueOnFail enabled. Error Triggers only catch *unhandled* errors. If you want the Error Trigger to fire, disable continueOnFail, or explicitly throw an error from your error-handling branch using a Function node: `throw new Error("Handled failure that needs alerting")` **Problem:** Workflow retries exhaust too quickly or too slowly **Symptom:** Getting bombarded with error alerts for transient issues, or workflows fail before the service recovers **Fix:** Adjust the retry count and delay based on the service's typical recovery time. For rate limits, check the `Retry-After` header and set your delay accordingly. For network issues, 3 retries with 2-3 second delays usually suffices. For service deployments, you might need 5 retries with 10-second delays. **Problem:** Static data shows undefined or doesn't persist **Symptom:** Accessing `$workflow.staticData.errorCount` returns undefined or always shows 0 **Fix:** Initialize the static data structure in workflow settings first. If running self-hosted n8n, verify the database connection is working—static data is stored in the database, not in memory. If using n8n cloud, check that you're not hitting execution limits that prevent writes. **Problem:** ContinueOnFail passes forward but downstream nodes fail unexpectedly **Symptom:** Nodes after the error point fail with "Cannot read property of undefined" **Fix:** When continueOnFail is enabled, the downstream node receives the error object, *not* your expected data structure. Always add an IF node immediately after any node with continueOnFail to separate the error path from the success path. Never assume data structure remains consistent. **Problem:** Error message truncated or missing context **Symptom:** Your error notifications say "An error occurred" without useful details **Fix:** The Error Trigger provides extensive context in its output. Make sure you're extracting `execution.error.message`, `execution.error.node.name`, and `execution.data.resultData.error.message`. Some errors include stack traces in `execution.error.stack`. For HTTP errors specifically, check `execution.error.cause.response.body` for API-specific error messages. **Problem:** Getting duplicate error notifications **Symptom:** Same error generates multiple Slack messages or emails **Fix:** You likely have both continueOnFail inline handling *and* an Error Trigger, and the inline handler explicitly throws. Choose one approach: either handle inline (with continueOnFail) or let it bubble up to Error Trigger, but not both unless you explicitly want escalation. Use workflow static data to implement debouncing: only alert if more than X minutes have passed since the last alert for this error type. **Problem:** Production workflows fail silently despite error handling **Symptom:** No errors logged, but data isn't processing and executions show as "success" **Fix:** This is the silent failure trap the article addresses. Check if you have continueOnFail enabled without any downstream error checking. A node can "succeed" by passing an error object forward. Always pair continueOnFail with explicit error detection in the next node. Search your workflow for nodes with continueOnFail enabled and verify each one flows into an IF node that checks for `$json.error`.