n8n workflow succeeded but produced no output
The execution is green, the duration is short, and the item count is zero. Sometimes that is correct — there genuinely was nothing to do. Sometimes it is an outage with a success badge on it. The difference is in the workflow's own history.
What it looks like in n8n
Open the run and the nodes are all green, but the data panel on the last node shows no items. Nothing was written, nothing was sent, and n8n is entirely satisfied with that.
- A success with zero items on a workflow that normally moves dozens.
- A run that finished far faster than usual.
- A last node that is a filter or an IF rather than the node that writes the result.
- A series of zero-item runs starting on one particular day.
Common root causes
Empty output is usually data-shaped rather than error-shaped, which is exactly why nothing throws.
A filter condition that stopped matching
A field was renamed upstream, a status value changed, a date format shifted. The condition is still valid and now matches nothing.
A query or API call returning an empty list
A changed parameter, a pagination reset, a deleted view or a tightened permission can all turn a full result into an empty one without an error.
Expired or downgraded credentials
Some APIs answer an unauthorised or unauthorised-scope request with an empty collection rather than a 401, so the node succeeds with nothing.
A changed upstream schema
An expression reading a field that no longer exists yields empty values. The run continues, writes blanks or nothing at all, and succeeds.
Deduplication that now matches everything
A dedup or “only new items” check comparing against the wrong key marks every item as already seen.
A timezone-shifted date window
A query for “yesterday” built in the wrong timezone can land on a window with no records in it.
How to check it manually today
The goal is to turn “empty and fine” into something the platform can tell apart from “empty and broken”.
Compare item counts over time
Look at the last weeks of runs for this workflow. If zero only started appearing on the 3rd, something changed on the 3rd.
Inspect the data on each node
Walk the run from the first node and find the one where the item count becomes zero. That node, or the one before it, is the cause.
Add an IF on item count
Right after the fetch, test the item count and route the zero case somewhere visible instead of letting it drain into the rest of the workflow.
Add a Stop and Error node on the empty path
If zero items means failure for this workflow, make n8n say so. A thrown error is something an Error Workflow can alert on; a success is not.
Record what normal is
Write down the usual item count and duration for the workflow. Without that number, nobody reviewing the execution list can tell that zero is wrong.
How OutcomeGuard detects it
OutcomeGuard already keeps the number you would otherwise have to remember.
- It learns each workflow's usual item count and how often an empty result is genuinely normal, then raises EMPTY_OUTPUT only when zero contradicts that history.
- It raises VOLUME_ANOMALY when item counts collapse without reaching zero — the half-empty import that nobody notices.
- It checks duration too, because a run that finished in a tenth of the usual time usually carried nothing.
- An Outcome Contract can require at least N items by a deadline, turning “empty is suspicious” into “empty is a failure”.
- A workflow where empty results are normal is left alone, and one with too little history is reported as insufficient data instead of as an anomaly.
See which successes are actually empty
The free health check compares every workflow's recent runs against its own history and lists the successes that produced nothing.