n8n silent failure: the workflow says success and nothing happened
A silent failure is an execution that ends without an error and without doing its job. n8n has nothing to report, so nothing alerts, and the gap is usually found days later by the person waiting for the data.
What it looks like in n8n
The execution list is a column of green. Durations look plausible. Open a run and it finished cleanly. And yet the sheet has no new rows, the CRM has no new lead, and the Slack channel has been quiet since Tuesday.
- Successful runs that now finish at an earlier node than they used to.
- Run durations that drop sharply — 400 ms where the job used to take 30 seconds.
- A webhook or polling trigger with no executions at all since a particular date, with no error to explain it.
- Item counts of zero on runs that used to move dozens of records.
Common root causes
Almost every silent failure comes from a path that ends quietly rather than a node that throws.
An IF or Filter branch that leads nowhere
The false branch has no nodes connected. When the condition flips, every item leaves through an unconnected output and the run still reports success.
A source node returning zero items
An empty API response or a query matching nothing is not an error. Downstream nodes receive nothing, do nothing, and succeed.
A trigger deactivated during an edit
Someone duplicated the workflow to test a change and left the original inactive, or the workflow was saved in an inactive state.
A changed webhook URL
Renaming or recreating the webhook node changes the path. The caller keeps posting to the old URL and gets no error from anyone who is watching.
A credential that expired
Some nodes handle a 401 by returning an empty result instead of raising. The run succeeds with nothing in it.
Continue On Fail left switched on
A node set to continue on failure passes the error along as data. The execution ends successfully while the work never happened.
How to check it manually today
You can catch a good share of silent failures with n8n alone, as long as you remember to look.
Sort executions by last node executed
Open a handful of recent successful runs and compare where they ended. A run ending earlier than usual is the clearest sign of a quiet break.
Compare durations
In the execution list, look at run times over the last weeks. A sudden, permanent drop usually means a branch stopped carrying items.
Add an IF on item count
After the node that fetches data, add an IF that checks the item count, and route the zero case into a node that notifies you.
Add a Stop and Error node
On the quiet path — the false branch, the empty result, the unexpected status — add a Stop and Error node so n8n records a real failure instead of a success.
Set up an Error Workflow
In workflow settings, point the Error Workflow at something that notifies you. It only fires on thrown errors, so do step 4 first to give it something to fire on.
How OutcomeGuard detects it
OutcomeGuard treats “success” as a claim to be checked against the workflow's own history, not as an answer.
- It learns which node successful runs normally end on, and raises SILENT_FAILURE when they start ending earlier.
- It learns the normal cadence of each trigger and raises a finding when a trigger simply goes quiet, with no error to show for it.
- It learns whether zero items is normal for this workflow, and raises EMPTY_OUTPUT only when it is not.
- It watches duration and volume against the workflow's own baseline, so a permanent collapse in either is visible.
- It refuses to judge a workflow with too little history, and says so, rather than guessing.
Find the silent ones
The free health check looks for exactly this pattern across every workflow on an instance. Read-only, about a minute, and the API key is discarded afterwards.