Continue On Fail Is Hiding Errors in Your n8n Workflow
Continue On Fail is doing exactly what you told it to. That is the problem.
You turned it on so one bad item would not kill an entire batch. Sensible. But the same setting that keeps the flow moving also keeps the execution green when a node errors, and your Error Trigger never fires, because from n8n’s point of view nothing failed. The node tripped, the flow continued, the log said success, and a node has been quietly failing on every run for weeks.
A failed node inside a green execution does not change the execution status. That is the whole trap in one sentence.
What it actually does to the status
In current n8n settings this lives under On Error. Many users still call it Continue On Fail. The On Error options are: Stop Workflow / Continue / Continue (using error output).
When a node errors and On Error is not set to stop the workflow, n8n does not treat that as a workflow failure. If On Error is set to Continue, the workflow proceeds using the last valid data. If it is set to Continue (using error output), the workflow proceeds and passes error information forward. Either way, the overall execution may not fail in the way your Error Workflow expects.
So the signals you normally trust can still say the run was fine. The status reads green, the executions list is calm, no alert went out. You can prove it to yourself: a node that throws on every run, with On Error set to continue, will give you a workflow that has been green for a month while doing only part of its job.
Why your Error Workflow never tells you
Most people protect important workflows with an Error Trigger. It is the standard advice and it is good advice, for the failures it can see. But an Error Workflow only fires when an execution fails, and Continue On Fail is designed to stop the execution from failing. The two cancel out. The node errors, Continue On Fail absorbs it, the execution stays green, and the Error Trigger has no failure to react to.
That is the cruel part. You did the responsible thing and added error handling, and the error handling is structurally unable to see this class of failure. You believe you are covered, and for this one you are not. It is one of the cleanest examples of the gap in the failures your Error Trigger never sees.
What it looks like in a real workflow
The most common shape is an HTTP node that fails on some items. You loop over records, call an API per record, and keep Continue On Fail on so one bad record does not stop the batch. Then the API starts rejecting a slice of requests: a rate limit, a changed field, an auth issue on certain accounts. Those items now carry an error instead of data. The workflow writes the good ones, finishes green, and the failed slice silently never gets processed. Nothing tells you coverage dropped.
A close second is a node that feeds a downstream step. The error-shaped item passes forward, the next node treats it as input, and you end up writing an error message into a field or skipping the real value, while the run still completes.
The quietest version is a node that fails every single time. It was set to Continue On Fail during testing, then failed permanently after a credential or endpoint change, and it has thrown on every run since. For a client process that means the output has been partly wrong for as long as nobody looked.
The native fix, and where it stops working
n8n does give you a way to react to a caught error inside the flow. After the node with Continue On Fail, add an IF or a Filter, test whether the item carries an error, and route the error items somewhere deliberate: a Stop And Error node to fail the run on purpose, a notification, or a separate log.
For critical workflows it is worth doing. But it is fragile. You have to remember to add it to every node that uses Continue On Fail. The error shape is not identical everywhere, so the check has to be written per node. It protects the workflows you thought about, not the ones you forgot. And across dozens of client workflows, “remember to wire an IF after every Continue On Fail node” is not a plan you can lean on. The native fix is correct and also depends on perfect discipline, forever.
What sees it, and what doesn’t
The structural fix is to stop trusting the execution status as proof and watch for caught errors directly.
| Signal | A tripped-but-green node |
|---|---|
| Execution status | Still green |
| Error Trigger / Error Workflow | Never fires |
| “Check for empty output” | False alarms (many nodes return nothing legitimately) |
| The error n8n records when a node trips | Visible |
That last row is the reliable one. An empty output is not the same as a failure, so guessing from emptiness produces noise. The dependable signal is the error n8n itself records when a node trips, even when the overall run finishes green.
That is what an outside watch reads. Instead of guessing from empty output, it reads the caught error from n8n’s own data, and surfaces it with the node name and a plain-language description, so a Continue-On-Fail error stops being invisible. You do not add anything inside your workflows and you do not have to remember an IF after every node.
A 60-second check you can run today
Pick one workflow that matters to a client. Which nodes have Continue On Fail enabled? For each one, if it errored on every run, would the execution still be green? And is there anything, anywhere, that would tell you a node tripped while the run stayed green?
If the answer to the last question is no, that workflow can be failing right now with a perfect green history.
Why this matters more for agencies
For your own workflows, a Continue-On-Fail node that quietly drops items is annoying. For a client’s workflow it is a slow trust problem. The client sees green runs and assumes everything is handled, while a slice of their leads, invoices, or syncs has been failing on every run, and the first person to notice is usually them. The execution log said success the whole time. That is the hard part to explain after the fact.
It is the same blind spot as an AI agent answering green over a failed tool, the scheduled run that never fired, and silent automation failures in general.
Check your workflow before the next quiet failure
A green execution is not always proof that the workflow did the job.
Run your exported n8n workflow through the free NoCrash Workflow Grader and get a quick read on the spots worth watching first. No access needed. No signup needed for the first look.
Run the free n8n Workflow Grader
If you want ongoing coverage after that, start free and watch up to 3 things continuously.