Workflow runs but nothing happens: find the silent failure

The complaint sounds harmless until you look at the invoices it costs you: the workflow runs but nothing happens. The execution list is a wall of green. No red badge, no email from n8n, no error anywhere, and yet the leads are not in the CRM, the documents are not generated, and the customer who filled the form on Tuesday is still waiting. "No error but not working" is the exact phrase people type into a search box at that point, and it is the one search where the vendor forums leave you with a wall of threads that nobody ever answered.

A green execution means only that no node threw an exception, and it says nothing at all about whether any work was done.

Read the item count on every node

Open the execution and walk left to right, reading the small item counter above each node. Here is a real run, from a form-to-CRM flow that had been "working" for days:

Execution 91744   Status: Success   Duration: 0.42 s

  Webhook               in 1    out 1    4 ms
  Code (normalise)      in 1    out 1    11 ms
  Filter (is qualified) in 1    out 0    2 ms
  Loop Over Items       in 0    out 0    1 ms
  HTTP Request (CRM)                     not executed
  Slack (notify AE)                      not executed

The run is a success by every measure n8n has. It is also completely useless. The Filter node received one item and emitted none, so everything downstream had nothing to do, and a node with no input does not run at all. n8n does not consider that an error, because it is not one in any technical sense; an empty result is a legitimate outcome for a filter.

Two weeks earlier, that Filter was evaluating a field called lead_score. Somebody in the CRM renamed it to leadScore. The Code node now writes undefined into the property the Filter reads, the comparison fails for every single lead, and the workflow has been quietly discarding all of them since.

Your workflow runs but nothing happens because nothing errored

People describe this in a few different ways, and they are all the same bug: the workflow executes but no output arrives, the run is green and the record is missing, the scenario finished in under a second and did nothing. Four shapes cover almost every case we have opened, and each one produces a green execution.

• Items get filtered to zero. A Filter, an IF branch, or a Remove Duplicates node drops everything, usually after a field rename or a change in the shape of the incoming payload.
• The error is inside a successful response. Plenty of APIs answer 200 with a body saying the record was rejected. n8n sees a 200 and moves on happily.
• Continue On Fail is switched on somewhere. This is the one that does real damage, because the error becomes ordinary data and travels downstream as though it were a record.
• The work happens somewhere you are not looking. The flow wrote to a sandbox account, a test spreadsheet, or the staging CRM, because a credential was swapped during testing and never swapped back.

That third one deserves the trace. With On Error set to continue using the regular output, a failed HTTP Request emits this:

[
  {
    "json": {
      "error": "Insufficient scope: contacts.write",
      "httpCode": "403"
    },
    "pairedItem": { "item": 0 }
  }
]

That is one item out, so the counter shows 1 and the tick is green. Downstream, a Set node maps id from that item, gets nothing, and a Google Sheets node appends a row of blanks. We have opened workflows in this state that had been running for months, producing a spreadsheet peppered with empty rows that everyone had learned to scroll past. A 403 there means the token is valid and the scope is gone, so it had been failing every time a contact needed writing, and the only visible symptom was blank rows.

There is a related setting worth knowing before it bites you. Always Output Data makes a node that returns nothing emit a single empty item instead:

[ { "json": {}, "pairedItem": { "item": 0 } } ]

People switch it on to stop a branch from stalling, and it does. It also converts "we found no matching customer" into "here is a customer with no fields", which then gets written to something.

Ten minutes of checks

1. Compare a working execution with a dead one, side by side. Find the last node where the two runs still agree on item counts. The node immediately after it is where your data goes missing, and this single comparison resolves more of these cases than everything else on this page.
2. Open the output of that node and read the actual JSON, expanding the item. Look for undefined values, an error property that has no business being there, or a field name in camelCase where your expression uses snake_case.
3. Check whether the trigger is even receiving what you think. In n8n, the Test URL of a webhook only listens while you have Listen For Test Event running, and the Production URL only answers while the workflow is active. A sender pointed at the wrong one gets a 404 and, depending on the sender, never tells you.
4. Look for pinned data. Pins apply to manual executions only, so a workflow can pass every test you run in the editor and process nothing in production, because the editor has been feeding it the same saved payload since March. The pin icon on the node is small and easy to stop seeing.

If step 3 turns up a trigger that has stopped firing entirely, the problem is upstream of everything described here, and the companion page on an automation that stopped working covers how to date the change.

Make a zero-output run wake somebody up

Nothing in n8n's built-in alerting will help you with any of the above. The Error Trigger fires on failures, and none of these are failures. A scenario that runs with no error and does nothing is invisible to every notification the platform offers, which is why the workflow at the top of this page ran empty for over a week before anyone asked where the leads had gone.

So you have to check for the absence of work directly. The health check on this page runs on a schedule, queries the executions API for a named list of workflows, and alerts when either of two things is true: a workflow that normally runs has not run at all in the window, or it ran and the final node produced zero items. Point it at the four or five flows where silence costs you money, set the window to something slightly longer than your normal gap between runs, and leave it alone.

We run six systems in production and every one of them has a version of this. The document generator we built for a hydrogeology consultancy is a good example of why. It has produced 168 documents and holds 349 boreholes on file as of August 2026, and its failure mode was never a crash. It was a run that finished in half a second having generated nothing, because a source file had a column header in a slightly different form that month. The check reports the count of documents produced per run, and a zero in that column arrives as a message before the client notices.

Counting output is the cheapest form of the thinking behind running evals on business automations: decide what a healthy run produces, then measure that on every run instead of trusting the colour of the badge.

When you do not need to hire anyone

Plenty of silent failures are a ten minute fix, and we would rather tell you that than take $500 to write it down. Do it yourself when:

• The comparison in step 1 lands on a Filter or an IF and the field name in the expression no longer matches the field name in the data. Fix the expression, retry the failed executions.
• You find pinned data on the trigger. Unpin it, run once in production, confirm real data arrives.
• A credential is pointed at a sandbox. Swap it, then go and check what has been written to the sandbox since, because those records still need to move.
• Continue On Fail is on for a node that writes records and you can see the underlying error in the item output. Turn it off, fix the error it was hiding, and expect the workflow to start failing loudly for a while. That is progress.

Call somebody when the missing data cannot be reproduced, when the flow depends on a Merge node whose behaviour nobody in the building can explain, when a Split In Batches loop over large JSON payloads makes memory grow until the container restarts mid-run and leaves half the records processed, or when you have found the bug and cannot tell how many records went missing while it was live. That last question is usually the expensive one, and it is the reason we start with a written diagnostic instead of a patch.

What a repair costs

The diagnostic is $500 and takes 3 business days. You get a written document naming the silent failure, the trace that proves it, an estimate of the records affected and how far back it goes, and a fixed quote to repair it. The $500 is credited in full against that quote. A single broken branch with alerting added afterwards usually lands at $750 to $1,500 in 2 to 5 days. When the same flow has several of these and the structure is the cause, it becomes a standard rescue at $1,500 to $4,000 over 1 to 2 weeks; a full rebuild is $4,000 to $10,000 over 2 to 4 weeks, and we only recommend one when patching would cost more than starting again. Every engagement carries a 30-day bug warranty.

Before you decide, two things worth reading: why automations die in production, where silent success is the failure mode we see most, and the production-ready checklist, which is what we hand over at the end of a rescue so the next silent failure lasts an hour instead of nine days.

If you want us to look, send the workflow name and a link to one green execution that should have done something to the rescue intake, or read how we work on the rescue page.