Four ways an n8n workflow reports success and does nothing

status: success

An upstream field gets renamed, or a value drifts out of range, and an IF condition that used to match stops matching. The nodes on that branch never run.

The obvious detection does not work. You would expect the skipped node to appear in runData with a non-success executionStatus. It does not appear at all. Checking node statuses for something that failed returns only healthy nodes.

Every minute    executionStatus=success   branches=[1]
Emit 5 rows     executionStatus=success   branches=[5]
Condition       executionStatus=success   branches=[0, 5]

declared but ABSENT from runData: ['Send invoice']

The signal is a missing key, not a bad value. To catch it you have to know which nodes normally run and notice one stopped — absence alone is not a fault, because the untaken side of an IF is absent on every healthy run too.

Reproduce it: Schedule Trigger → Code node emitting a few rows → IF that can never match → Code node on the true branch. Read data.resultData.runData from the execution. The true-branch node simply is not there.

no HTTP status at all

An OAuth token expires. n8n fails at the signing step, before any request goes out, with something like Unable to sign without access token.

There is no status code to catch. Error handling built around HTTP responses — retry on 5xx, alert on 4xx — never sees this, because no HTTP exchange happened.

status: success

Someone disables a node to test something and does not re-enable it. On a production run a disabled node passes its input to the next node untouched.

The enrichment, validation or transformation that node was doing silently stops happening. The row count is unchanged, so anything checking volume sees nothing wrong. The data is simply less correct than it was.

success · non-zero rows

Zero rows is the easy case and almost everyone checks for it. The expensive case is the run that quietly returns most of what it should, because it passes every emptiness assertion ever written, including a fixed floor.

A fixed threshold cannot catch this and a flat average makes it worse. Compare each run against a median of comparable runs instead — and give the baseline a calendar, because a client whose Monday is legitimately ten times its Tuesday will either alert every Monday or hide a collapsed one behind the week's average.