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 is a silent failure in n8n?
A silent failure is an execution that n8n records as successful although the work it exists to do did not happen. No node threw, so the Error Workflow never ran and nothing turned red; the failure is visible only in the result — missing rows, no email, a file that did not change — and usually only to the person waiting for it.
The six kinds of silent failure
“Silent failure” is used for several different situations. They have different causes and are detected in different ways, so it helps to name them. The last column is the signal OutcomeGuard raises for each.
| Kind | What you see in n8n | Typical cause | OutcomeGuard signal |
|---|---|---|---|
| Missed run | No execution at all after a certain date | Deactivated workflow, timezone or cron mistake, instance restart, upstream caller stopped | Missed run |
| Stopped early | Green runs that end at an earlier node than they used to | An IF or Filter branch with nothing connected, a Switch case that no longer matches | Silent failure |
| Empty success | Green runs with 0 items where there used to be dozens | Empty API response, a query matching nothing, a credential returning an empty result instead of an error | Empty output |
| Stale output | Green runs that keep producing the same result | Upstream data frozen, a cached response, a filter fixed on an old date | Stale output |
| Volume collapse | Green runs moving far fewer items than usual, but not zero | Pagination broken after the first page, a partial upstream outage, a rate limit returning 200 with a short list | Volume anomaly |
| Outcome not met | Green run; the business result did not happen | The run finished but did not reach the node that writes, or wrote fewer than the job required | Outcome not met (Outcome Contract) |
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.
Frequently asked questions
- Why does n8n show success when the workflow did nothing?
- n8n reports the execution, not the outcome. If no node throws, the execution is a success, even when every item left through an unconnected branch or the source returned zero items.
- Does the n8n Error Workflow catch silent failures?
- No. It runs only when an execution throws. To make a quiet path visible to it, add a Stop and Error node on that path so n8n records a real failure.
- How do I detect a silent failure in n8n?
- Compare recent successful runs with the workflow's own history: the node they end on, the item count, the duration and the cadence. A run that ends earlier, carries nothing, finishes in a tenth of the time or simply stops arriving is the signal. OutcomeGuard does this comparison automatically through the API.
- What is the difference between a silent failure and a missed run?
- A missed run is the absence of an execution when one was due. A silent failure is an execution that happened, succeeded and achieved nothing. Both are silent because n8n has no error to report; they are detected differently.
- Can Continue On Fail cause silent failures?
- Yes. A node set to continue on failure passes the error along as data, and the execution ends successfully while the work never happened. Use it only where you handle the error path explicitly.