n8n Continue on Fail: Keep Good Items Moving Without Hiding Broken Ones

Continue on Fail is the n8n setting you use when one bad item should not stop the whole workflow. It lets successful items keep moving while failed items carry error details forward for review, logging, or repair.

That matters in production. A lead enrichment workflow should not stop because one company has a missing domain. An invoice import should not discard ninety clean rows because one row has a malformed amount. A support triage workflow should not freeze every ticket because one attachment fails to parse.

Quick answer: what Continue on Fail does

When Continue on Fail is enabled on a node, n8n keeps executing the workflow even if that node fails for an item. Instead of stopping the entire run, the failed item can continue with error information attached. Clean items continue as normal.

Use it when failures are expected, isolated, and recoverable. Do not use it when a failed node means the rest of the workflow would make unsafe changes, such as charging a customer, deleting data, or writing incomplete records to production.

The safe pattern

The safest Continue on Fail pattern has three parts: let good items continue, route failed items somewhere visible, and stop risky downstream actions from using broken data. The setting is not a substitute for error handling. It is a way to keep batch work moving while preserving evidence.

• Enable Continue on Fail only on the node where isolated failures are acceptable.
• Add an IF or Filter node after it to separate clean results from errored items.
• Send failed items to Slack, email, a database table, or a manual review queue.
• Include the original item, the failed node name, and the error message in the review payload.
• Keep destructive or customer-facing actions behind a clean-item branch only.

When to use it

Use Continue on Fail for enrichment, parsing, lookup, notification, and non-critical API calls. These are places where one item can fail without invalidating every other item in the run.

For example, a CRM enrichment workflow might look up company size from a third-party API. If the lookup fails for one lead, the workflow can still create tasks for the other leads. The failed item can go to a review queue with the original email, company domain, and API error.

A document automation workflow is another good fit. If one PDF cannot be parsed, Continue on Fail can keep the remaining files moving through extraction and storage while the failed file is flagged for manual review.

When not to use it

Do not use Continue on Fail to hide failures that should stop the workflow. If the failed step validates payment status, checks consent, confirms inventory, or verifies the customer record, continuing can create bad downstream effects.

The question is simple: if this node fails, can the next node still make a correct decision? If the answer is no, let the workflow fail loudly or branch into a repair path before any risky action runs.

Continue on Fail versus an Error Trigger

Continue on Fail is item-level control inside a workflow. It helps the current execution keep going when a node fails. An Error Trigger is workflow-level recovery. It starts a separate workflow when another workflow fails.

Use Continue on Fail when you expect partial failures inside a batch and want to keep clean items moving. Use an Error Trigger when the whole workflow failure needs alerting, incident handling, or a separate recovery workflow.

How to structure the review branch

A good review branch should not just say something failed. It should tell the operator what failed, where it failed, and what input caused it. Include the workflow name, execution ID when available, source system, item identifier, raw error message, and the next recommended action.

For lead workflows, the review branch might write failed enrichment attempts into a table with email, company domain, CRM owner, error text, and retry status. For invoice workflows, it might store vendor, filename, row number, amount, and parse error. For support workflows, it might store ticket ID, attachment URL, and parsing status.

Common mistakes

• Turning Continue on Fail on everywhere, then losing track of which node actually failed.
• Letting failed items continue into CRM, email, payment, or database write nodes without a clean/error split.
• Sending only the error message to review, with no original item data.
• Treating Continue on Fail as monitoring instead of adding a real alert or review queue.
• Using it on validation steps where failure should stop the workflow.

A practical n8n workflow shape

For a batch import, start with the source trigger, normalize the item shape, run the risky lookup or parser with Continue on Fail enabled, then split the output. Clean items continue to the business action. Failed items go to a review table with enough context to retry or fix manually.

That shape works for quote requests, inbound leads, invoices, support attachments, product feeds, and enrichment jobs. It keeps throughput high without pretending every record succeeded.

Where Synta helps

Synta is useful when you know the outcome you want but do not want to wire every guardrail by hand. Describe the node that may fail, what counts as a safe item, what should happen to failed items, and which downstream actions must never receive broken data.

That gives the generated n8n workflow a safer structure: normalization first, Continue on Fail in the narrow spot where it belongs, clean/error branching, and a review queue that keeps failures visible.

Try the Synta MCP workflow builder

If you are building an n8n workflow that needs partial failure handling, use the tracked Synta MCP path here: open Synta MCP. Describe the risky node, the clean-item rule, and where failed items should be reviewed.

FAQ

Does Continue on Fail mean the node succeeded?

No. It means the workflow can continue even though the node failed for an item. You still need to inspect and route the error data.

Should I enable it on every node?

No. Enable it only where partial failure is acceptable and where the next step can safely separate clean items from failed items.

Is Continue on Fail the same as retrying?

No. Continue on Fail keeps execution moving. Retrying means attempting the failed operation again. Many workflows need both: continue safely now, then retry failed items from a review queue.

What should failed items include?

Keep the original item, the node that failed, the error message, and enough identifiers for a human or retry workflow to fix the issue later.