When the run is green and the answer is wrong
A failed run is the easy case. It goes red, the Error Workflow fires, somebody gets a message. These four report success and write bad data — so nothing fires, and nobody looks.
Every one of the four below produces a green execution. The run summary is clean. The Executions list shows success. An Error Workflow attached to the whole thing stays silent, because from the platform's point of view nothing went wrong.
They are all recurring complaints in the n8n community forum, and they share one property: the error handling everyone builds first cannot see any of them. Catching them needs a different kind of check — an assertion about the shape of the result, not a listener for exceptions.
Each tab shows the run as it appears, the data it actually wrote, and the specific check that catches it.
The scrape returned nothing, and that counted as successrun: success
The source changed its markup. The selector matched zero elements. Returning an empty list is not an error, so the node succeeded and the workflow carried on.
IF node
immediately after the extract, routing items.length === 0 to the failure path
rather than letting it fall through as success.
Every field was populated, and one of them was nonsenserun: success
A mapping pointed at the wrong source field. The value is present, is a string, and is not empty — so required-field checks and type checks both pass. It is simply the wrong thing.
The caller retried, and both runs succeededrun: success ×2
The webhook did its CRM work before responding, so the acknowledgement came back slowly. The sender timed out and retried. Two executions ran. Both were correct in isolation.
There was no run at all, and no error eitherrun: none
A node failed validation — a credential went missing, or a required parameter was cleared. n8n checks this before starting an execution, so the execution never begins. There is no failed run, because there is no run.
The common thread
None of these four are exotic. Each one is a normal day in a system that is working as designed — and in every case the error handling is silent, because there is no error. The run succeeded. That is the problem.
Error handling tells you a run failed. It cannot tell you a run succeeded and produced the wrong answer.
The fix is not more error handling. It is a small number of assertions about what a correct result looks like — a count, a shape, a uniqueness constraint, a heartbeat — placed where a wrong answer would otherwise pass through quietly. They cost very little at build time and are tedious to retrofit once the bad data is already downstream.
If you are auditing something you already run, the fastest first pass is to ask, for each scheduled workflow: would I notice if this quietly stopped? The answer is usually no for more of them than expected.
The workflow patterns behind these checks are on our GitHub, free and MIT licensed: github.com/clearstack-studio/automation-patterns. Take them, adapt them, no attribution needed.
ClearStack Studio builds and repairs automations across n8n, Make and Google Sheets, with the reliability work above included rather than sold separately. See what we do.