n8n continue on fail – how the error output and retry settings actually work

 

Who this is for: Automation engineers and n8n power‑users who need production‑grade reliability when individual steps may error. We cover this in detail in the n8n Production Failure Patterns Guide.

Quick Diagnosis

Your workflow stops as soon as any node throws an error, even if earlier nodes succeeded. This leaves you with partially processed data and no built‑in recovery path.

Featured‑Snippet Solution
Enable Continue On Fail on tolerant nodes, capture errors with an IF node (or the node’s Error output), log them, and route failures to a dedicated Error Trigger workflow for retry, alerting, or dead‑letter handling.

1. n8n’s Default Failure Behavior

If you encounter any n8n idempotency retry failures resolve them before continuing with the setup.

Situation	Default Action	Why It Breaks Partial Workflows
Node throws an exception (e.g., API 429)	Stops the whole execution and marks the run failed	Successful earlier nodes can’t be rolled back; downstream steps never run.
Multiple parallel branches	First error aborts the entire execution tree	Data that succeeded in other branches is left unprocessed.
Retry on error disabled	No automatic retry; manual intervention needed	Time‑sensitive pipelines stall, increasing latency.

EEFA note: Silent failures cause data drift. Design a “failure‑aware” path instead of relying on the default abort.

2. Core Strategies for Partial‑Failure Handling

Below each strategy is presented in its own focused table (max 4 columns).

2.1 Continue On Fail (node‑level)

When to Use	Key Settings	Pros	Cons
Non‑critical external calls (optional enrichment)	Toggle Continue On Fail in the node UI	Keeps workflow alive; simple to enable	Errors are hidden; you must capture them manually.

2.2 Error Trigger + Separate Error Workflow

When to Use	Key Settings	Pros	Cons
Critical steps needing audit/retry	Add an Error Trigger workflow, enable *Workflow Execution → Error Trigger*	Centralized error handling, can retry, notify, or dead‑letter	Slightly more complex; extra workflow to maintain.

2.3 IF / Switch Node with “Error” Output

When to Use	Key Settings	Pros	Cons
Branching logic based on success/failure	Connect the node’s *Error* output to an IF or Switch node	Granular per‑node control	Requires wiring each node manually.

2.4 Batch Processing with “Execute Workflow” (Run Once per Item)

When to Use	Key Settings	Pros	Cons
Large data sets where individual items may fail	Use SplitInBatches → Execute Workflow (child) with Continue On Fail	Isolates failures to single items	Increases execution count; watch quota limits.

2.5 Custom JavaScript Try/Catch

When to Use	Key Settings	Pros	Cons
Complex transformations needing fine‑grained error handling	Wrap logic in a Function node using try { … } catch (e) { … }	Full control over error objects	Requires JS expertise; harder to debug in UI.

Pick the strategy that matches the step’s criticality and the observability you need. If you encounter any n8n silent failures no logs resolve them before continuing with the setup.

3. Implementing “Continue On Fail” + Error Capture (Most Common Pattern)

3.1 Enable Continue On Fail

1. Open the node that may error (e.g., HTTP Request).
2. In Settings, toggle Continue On Fail.
3. Save the node.

EEFA: Only enable this on nodes whose failure does not compromise downstream data integrity (never for payment processing).

3.2 Capture Errors with an IF Node

Purpose – Detect whether the previous node returned an error field and branch accordingly.

{
  "parameters": {
    "conditions": {
      "boolean": [
        {
          "value1": "={{$json[\"error\"]}}",
          "operation": "isNotEmpty"
        }
      ]
    }
  },
  "name": "IF error?",
  "type": "n8n-nodes-base.if",
  "typeVersion": 2,
  "position": [500, 300]
}

*Explanation*: The IF node checks for the presence of error. If true, execution follows the **Error** branch; otherwise it proceeds to the **Success** branch.

3.3 Log Errors to a Google Sheet (Production‑Ready Example)

Purpose – Persist error details for later analysis and manual retry.

{
  "parameters": {
    "sheetId": "1aBcDeFgHiJkLmNoPqRsTuVwXyZ",
    "range": "Errors!A:D",
    "values": [
      [
        "={{$json[\"error\"][\"message\"]}}",
        "={{$json[\"error\"][\"code\"]}}",
        "={{$json[\"requestUrl\"]}}",
        "={{$now}}"
      ]
    ]
  },
  "name": "Google Sheet – Log",
  "type": "n8n-nodes-base.googleSheets",
  "typeVersion": 1,
  "position": [750, 300]
}

EEFA: Google Sheets API has per‑minute write quotas. Buffer errors in an array and write in batches of ≤ 100 rows to stay within limits. If you encounter any n8n long running workflow failures resolve them before continuing with the setup.

3.4 Wiring the Nodes (Connection Overview)

From Node	To Node	Output
HTTP Request (Continue On Fail)	IF error?	main
IF error? (true)	Google Sheet – Log	main
IF error? (false)	Next workflow step	main

4. Centralized Error Workflow Using the Error Trigger

4.1 Create the Error Trigger Workflow

1. New Workflow → Trigger → Error Trigger.
2. (Optional) Set **Workflow ID** to target a specific primary workflow; leave blank to catch all.
3. Add a **Set** node to initialise a retryCount field.
4. Add a **Switch** node to route by error.code (e.g., 429 = rate‑limit).

4.2 Automatic Retry for Rate‑Limit Errors

Purpose – Back‑off and retry when the API signals “Too Many Requests”.

{
  "parameters": {
    "value": "0",
    "valueType": "number"
  },
  "name": "Set retryCount = 0",
  "type": "n8n-nodes-base.set",
  "typeVersion": 2,
  "position": [250, 200]
}

{
  "parameters": {
    "value": "{{$json[\"retryCount\"] + 1}}"
  },
  "name": "Increment retryCount",
  "type": "n8n-nodes-base.set",
  "typeVersion": 2,
  "position": [650, 400]
}

{
  "parameters": {
    "delay": "={{Math.pow(2, $json[\"retryCount\"]) * 1000}}"
  },
  "name": "Exponential Back‑off Delay",
  "type": "n8n-nodes-base.wait",
  "typeVersion": 2,
  "position": [850, 400]
}

{
  "parameters": {
    "workflowId": "<>",
    "executeOnce": true
  },
  "name": "Retry Original Workflow",
  "type": "n8n-nodes-base.executeWorkflow",
  "typeVersion": 2,
  "position": [1050, 400]
}

Key safeguards
– Add a condition before the retry step: if retryCount > 5 → Notify & Stop.
– Use the Switch node to separate non‑retryable errors (e.g., validation) and route them to a Slack notification node.

5. Checklist: Deploying a Robust Partial‑Failure Strategy

• Identify non‑critical vs critical nodes.
• Enable Continue On Fail *only* on non‑critical nodes.
• Add an IF node (or use the node’s built‑in *Error* output) to capture errors.
• Log errors to a durable store (Google Sheets, PostgreSQL, S3).
• Build a **central Error Trigger workflow** for retries, alerts, or dead‑letter routing.
• Implement **exponential back‑off** for rate‑limit errors.
• Set a **max‑retry ceiling** (e.g., 5 attempts) to avoid runaway loops.
• Monitor execution counts against your n8n plan quota.
• Test with both **success** and **forced‑failure** payloads (use a mock API that returns 500).
• Document the failure‑handling flow in your internal wiki for future maintainers.

6. Real‑World Troubleshooting Scenarios

Symptom	Likely Cause	Fix
Workflow still aborts despite “Continue On Fail”	Node does **not support** the flag (e.g., *Webhook* node)	Wrap the call in a **Function** node with try/catch and manually return { data, error }.
Error Trigger receives **duplicate** events	Primary workflow also has built‑in retry enabled	Disable the node’s **Retry on Fail**; let the error workflow handle retries only.
Error logs contain **undefined** fields	Different APIs return different error shapes (message vs msg)	Normalise in a **Function** node: const err = $json.error || { message: $json.msg, code: $json.status };
High execution count → **quota exceeded**	Using *SplitInBatches* with batch size = 1	Increase batch size or consolidate error writes into a single batch operation.

EEFA: Always test against a sandbox API before production. Production endpoints often enforce stricter rate limits that can mask hidden bugs.

7. Conclusion

Enable Continue On Fail on tolerant nodes, capture errors with an IF node or the node’s *Error* output, log them, and use an Error Trigger workflow to retry, notify, or move failed items to a dead‑letter queue.