You check n8n. Executions are green. No errors in the log. You check the actual output — whatever the workflow was supposed to do didn't happen. No email sent. No row updated. No record created.
This is the frustrating version of automation failure. Not a red X. A green check that lied.
There are six patterns that produce this, and they show up constantly in production n8n builds. Here's what to look for — and one fix at the end that catches all of them without per-node instrumentation.
The patterns that fool the green check
Empty IF branches. The IF node has two outputs: true and false. If the false branch isn't wired to anything, every item that fails the condition disappears — silently, without error. n8n doesn't warn you about unconnected outputs. The node runs, the count drops, those items are gone. Wire both outputs somewhere, even a No Op node you never check, so nothing vanishes unaccounted for.
Keep Only Set stripping fields downstream nodes expect. The Edit Fields (Set) node has a "Keep Only Set" toggle. Enable it and every field not on your explicit list gets dropped before the next node sees the item. If a downstream node expects a field you forgot to include, it gets undefined and may produce empty output rather than an error. Check the per-node output when you suspect this — the field count before and after will tell you immediately.
Early loop exits. SplitInBatches doesn't always finish what you think. A count mismatch or an unexpected empty batch can cause the loop to exit before it processes every item. The execution finishes green because nothing failed — the loop just stopped. Compare your input count to your output count before trusting the green check mark.
Stale webhook URLs. n8n gives you two webhook URLs: one for testing (active only while the editor is open) and one for production (active only on live workflows). If you wired the external service to the test URL during development and never updated it, events disappear into the void. The execution log is empty because no trigger ever fired. It looks like nothing ran because nothing did.
HTTP 200 with an error body. An API returns status 200 but the response body contains {"status": "error", "message": "..."}. n8n calls it success, passes the error body to the next node, and that node processes it as if it were real data. I covered the detection and fix pattern for this specifically in When n8n runs green but the write never landed.
And then there's Continue On Fail, which deserves its own section.
Why Continue On Fail is the hardest one to catch
Continue On Fail is a per-node setting that stops a failing node from halting the entire workflow. When a node fails on a particular item with this enabled, n8n adds an error key to the output JSON and keeps going. The execution finishes green.
The problem: downstream nodes have no idea they're processing an error object. They run their logic on whatever's in $json — which is now an error message string instead of the data structure they expect. Output is garbage. Execution looks clean.
Continue On Fail converts a hard failure into a silent one. The item doesn't stop — it keeps moving through the workflow, carrying the error as if it were real data.
The fix is an IF node immediately after any node with Continue On Fail turned on. Check {{ $json["error"] }} — if it's not empty, route those items to an error path. A Slack alert, a dead-letter Airtable row, a simple notification node. Anything you'll actually see. Don't leave the error branch unconnected; that's exactly the empty-IF-branch problem again, one step downstream.
This pattern — Continue On Fail without an error check after it — is the one most often missing from production workflows that look fine until something breaks badly. An n8n community PSA on this from late 2025 still comes up regularly because builders keep running into it.
One monitoring pattern that catches all six
Each pattern has its own fix. But there's a monitoring approach that catches all of them without per-pattern instrumentation: the heartbeat.
At the very end of your workflow — after everything that's supposed to happen — write a timestamp to somewhere you can query. An Airtable row, a Google Sheet cell, an n8n data store, a simple database table. One write: "last successful run: [datetime]."
Then build a second workflow that runs on a schedule, reads that timestamp, and alerts if it's older than your expected cadence plus a grace period. If the main workflow runs every hour, alert when the timestamp is more than 90 minutes old.
Alerting on absence catches every failure mode at once — because they all end the same way: the timestamp never got written.
A workflow that stopped firing won't write it. One that exited a loop early won't reach the write. A Continue On Fail cascade that corrupted every item will still skip the write if anything after the failure depended on clean data. Silence is the common output of all six patterns, and a heartbeat watches for exactly that.
The cost is low — two extra nodes, one data store read in the monitoring workflow. What it gives you is a real failure signal instead of finding out three days later that nothing has been running.
Where to start with existing workflows
Before adding monitoring to everything, do a quick pass on the workflows already in production:
- Every IF node: are both outputs wired to something?
- Every Edit Fields node with "Keep Only Set": does the field list match what downstream nodes actually expect?
- Every node with Continue On Fail enabled: is there an IF check immediately after it?
- Webhook-triggered workflows: is the external service pointing to the production URL, not the test one?
- Any schedule-based workflow that touches real data: add the heartbeat timestamp write at the end.
If you're running n8n AI agent workflows where model output drives downstream nodes, there's a separate class of silent failure worth knowing about — schema-valid but semantically wrong output that never triggers an error handler. See Silent AI workflow errors in n8n for the Code node validation pattern that catches it without extra model calls.
And if you want the automation architecture set up correctly before it goes anywhere near production, our automation services include the monitoring layer — not just the happy path.
— Cole
Sources
- n8n Community: "The silent failure: when your n8n workflow succeeds but does nothing" — the discussion that prompted this post
- n8n Community PSA: Continue On Fail silently swallows node errors