Why does my n8n workflow say Success but nothing happened?

Because n8n's "Success" only means no node threw an error. It doesn't mean any data got through. If a step returns 0 items, the nodes after it usually don't run, and the execution still ends green. No error is raised, so your Error Workflow never fires either.

That's why these failures are found late, usually by a client asking where their leads went.

What "Success" actually checks

An n8n execution is marked successful when it reaches the end without an unhandled error. Whether a node produced 10 items or 0 doesn't change that. When a node outputs nothing, n8n doesn't run the nodes connected after it by default. So a workflow that was meant to read rows, filter them and write to a CRM can "succeed" after only the first step.

The Error Workflow (set under Workflow settings → Error workflow) is started only when an execution fails (n8n docs: error handling). A run that quietly did nothing isn't a failure, so you get no alert. For a side-by-side of what it catches and what it can't, see RunLookout vs n8n Error Workflow.

The 5 usual causes

These come up again and again on the n8n forum. The thread "The silent failure: when your n8n workflow succeeds but does nothing" and "How do you catch workflows that run fine but do nothing?" are full of them. Our guide to 7 ways an n8n workflow fails silently covers more of these.

1. A lookup returns nothing. A Google Sheets, database or CRM search finds no rows. Often that's because a column or field was renamed, or a filter value changed. The run is green. Nothing downstream runs.

Worse, sometimes the empty result is read as an answer. One user on X described a Sheets lookup that failed and came back empty, which the workflow took as "no duplicate", so it wrote the same row twice.

2. An IF or Switch branch that ends with no node. The "should never happen" branch has no node after it, so items that land there disappear. The Switch node's fallback output is a common case (forum example).

3. An API that answers 200 with an empty or wrong body. The HTTP Request node succeeds because the server replied. The list inside is empty, or the shape changed and your expressions now resolve to nothing (forum example).

4. A credential that stopped seeing data. An expired or downgraded OAuth token sometimes errors out, which is the good case. Sometimes it returns an empty result because the account can no longer see the records.

5. A trigger with nothing to pick up. A polling trigger finds no new items, which is fine once. If it's every run for a week, something upstream broke: the form, the webhook sender or the source app.

How to check a run that "succeeded"

Open the execution and look at item counts, not colours:

1. Go to Executions, open the run, and click through the nodes in order.
2. Find the first node that shows 0 items (or no output). That's where the data stopped.
3. Look at that node's input. Is the data there but filtered out (an IF, Filter or Switch problem), or did the node return nothing from an outside system (a lookup or API problem)?
4. Re-run that node alone with the same input to confirm.

If you see the same 0 at the same node across several days of runs, it isn't bad luck. Something changed.

How to stop it happening silently

Make the important path fail loudly. After the step that must return data, add an IF node that checks the item count. Route the empty case to a Stop and Error node (docs). Now an empty result becomes a real failure, and your Error Workflow fires.

Be careful with "Always Output Data". This node setting makes a node output one empty item instead of nothing, so the next nodes run. It's useful when you want to handle the empty case yourself. It's dangerous when you forget, because the next nodes now run on a blank item and can write empty records.

End every branch on purpose. Any branch that "shouldn't happen" should end in an alert, not in nothing.

Watch the counts from outside. Hardening each workflow works, but it doesn't scale well. Every check is one more node to maintain, per workflow, per client. The other way is to read executions through the n8n API and check how many items a chosen step produced on each run.

That's what we built RunLookout for. You pick the step that should always return something, and if a run finishes green but that step produced 0 items, you get an alert by email, Slack or Telegram, with a short note you can forward to the client. It also covers runs that fail, schedules that don't run, and servers that go down. It's read-only and adds nothing to your workflows. 14 days free, no card.

Our opinion

Make the critical path fail loudly first. A Stop and Error node after your most important lookup takes five minutes and catches the worst case. Outside monitoring is the backstop for the twenty other paths you'll never get round to hardening, and for workflows other people built.

A limitation to know about

Counting items catches "nothing happened". It doesn't catch "the wrong thing happened". If a step returns 50 items but they're the wrong 50, or a field is filled with the wrong value, the counts look normal. For that you still need checks on the data itself, like a required field being present, or a sample record compared against what you expect.

FAQ

Does the n8n Error Workflow catch empty runs?
No. It only starts when an execution fails. A run that ends green with 0 items isn't a failure.

How do I make n8n fail when a node returns no items?
Add an IF node after it that checks whether there are items, and send the empty branch to a Stop and Error node. The execution then fails, and your Error Workflow runs.

Why do nodes after an empty node not run?
By default, n8n runs a node only for the items it receives. With 0 items, the next node has nothing to process, so it doesn't run. The "Always Output Data" setting changes that by sending one empty item.

Is this an n8n bug?
No. "Success" means "no errors", and that's a reasonable definition. The gap is that "no errors" and "did its job" aren't the same thing, and nothing tells you the difference unless you check.

Does this happen on n8n Cloud too?
Yes. It's about how executions are judged, not where n8n runs.

We make RunLookout. We're not affiliated with n8n GmbH.