Your n8n workflow is green and the data is still wrong

The workflow ran. Every node is green. The execution list shows an unbroken column of successes going back weeks. And the data is wrong.

This is the most expensive failure mode in automation and the hardest to catch, because nothing asks for your attention. A workflow that crashes gets fixed the same day. A workflow that succeeds on incomplete data can run wrong for months, and by the time somebody notices the gap, it is weeks deep and nobody trusts the numbers any more.

The one that catches everybody

Here is the shape of it, from a real rescue job. A workflow synced online store orders into a spreadsheet every morning. It worked perfectly for a year. Then new orders stopped appearing — no error, no alert, every execution green.

The node fetching orders had its Return All option switched off. With it off, the node fetches the first page of results and stops. That was invisible while the store did twenty or thirty orders a day, because one page was always enough.

Daily volume crossed the page limit in August. From that point every run silently discarded the remainder. Nothing threw an exception — the node did exactly what it was configured to do — so the platform marked each execution successful and nobody had a reason to look.

The workflow was never failing. It was succeeding on incomplete data.

Almost every node that returns a list has this switch, and the default is usually the safe-looking one that quietly caps your results. It is the single most common cause of "my automation stopped working but there are no errors".

The other four silent failures

A field that resolves to nothing. Rename a field upstream, or hit an API that omits a key when it is empty, and the expression reading it returns nothing at all. That is not treated as an error. An empty value passes downstream and you get a record written with a blank email address rather than a failed run. This is worse than a crash, because the record exists. It looks like data. It just is not.

An empty result treated as success. A search finds nothing. A filter excludes everything. The workflow runs to the end with zero items, completes cleanly and reports success. Green execution, nothing written, nobody told. An empty batch is almost never a legitimate outcome for a scheduled sync — if your workflow runs daily and finds nothing to do, that is either a genuinely quiet day or a broken query, and you want to know which.

Items multiplying where you expected one. An API starts returning an array where it used to return a single object, and suddenly every node after it runs once per element. Your "send one summary email" becomes forty emails. All forty succeed. The execution is green and somebody’s inbox is not.

Partial success inside a loop. With continue-on-fail enabled — which is often the right choice — one bad item does not stop the run. But if nothing downstream inspects the error output, those failures vanish without trace. The run is green because the workflow finished, not because the work did.

Why the platform cannot catch these for you

Success and failure states describe execution, not correctness. Green means every node ran and none threw an exception. It makes no claim about whether the data that came out is right, complete or sane. It cannot — it has no idea what your data is supposed to look like.

That is not a flaw, and every workflow engine works this way. But it does mean correctness checks are your job, and most workflows have none at all.

Four checks that catch nearly all of it

Assert the count. After any step that fetches a list, compare the number of items against what you expect. Not an exact figure — a floor, and a ceiling. Fewer than one item on a daily sync deserves an alert. So does a count that lands exactly on a round number like 50, 100 or 250, because an item count that exactly equals a round number is nearly always a pagination cap rather than a coincidence.

Treat empty as a fault. Route zero-item results to an alert instead of letting them finish quietly. If a quiet day really is normal for that workflow, make the alert say so rather than removing the check.

Validate the fields you depend on. Before writing anything, confirm the handful of fields you actually use are present and the right type, and stop the run loudly when they are not. This costs about five minutes and catches every silently renamed field for the life of the workflow. The point is to convert a silent failure into a noisy one.

Reconcile against the source. The strongest check, and the one almost nobody builds. Once a day, count the records at the source and count what you wrote, and send an email when the two disagree. This is the only check that catches problems you did not anticipate — everything else only finds the failure modes you already thought of.

Make sure somebody hears the alarm

All of the above only helps if the alert reaches a person. n8n lets you nominate a separate workflow that runs whenever any other workflow fails. Build one — it emails you the workflow name, the execution ID and the error — and set it on every workflow on the instance.

It takes about thirty minutes, once, and it means a failure at two in the morning reaches somebody instead of sitting in a log nobody opens. In the case above, the reason the problem survived five weeks was not that it was hard to spot. It was that nothing was looking.

The principle

Green means it ran. It does not mean it worked.

Anyone can wire up the happy path — a trigger, three steps, a write. What separates an automation you can trust from one you merely hope about is the branches: what happens when the API changes shape, when the list runs longer than one page, when the field arrives empty, when nothing comes back at all.

Those branches are where the value is, and they are the first thing missing from every broken workflow we are asked to look at.