When a workflow crashes, you find out. When it runs, reports success, and quietly does nothing — you find out three days later, from your client.
lead-router stopped checking in 41 minutes ago — and n8n still reports every run as completed.
None of these throw. Every one of them is invisible until someone downstream complains. Reproductions and what n8n actually records →
A node calls an API, the quota has run out, the reply is 200 with an empty body. The node ran, so it is green. Everything downstream processed an empty string — correctly, and pointlessly. The same shape when a field comes back as an array where a string belongs: present, not empty, and wrong.
The token fails at the signing step, before the request ever leaves. Error handling built around status codes never sees a thing.
In queue mode both the workflow Timeout and EXECUTIONS_TIMEOUT are ignored. Open as issue #36343 — reported three times, still unfixed.
A condition that can no longer match doesn't error — it skips, and the run still reports success. One instance was found carrying 27 of them.
I published the reproduction rather than the conclusion, so anyone running n8n could check it against their own instance instead of taking my word for it.
The skipped-branch behaviour was posted to r/n8n with a four-node workflow that reproduces it. Three operators confirmed it on their own instances within a day. One reported that it holds across 2.x releases rather than only the 2.36.7 I had tested, which is a wider claim than I was able to make on my own.
That same operator first argued for the conventional fix, which is adding a dummy node to every branch so something always writes to the run data. After I pointed out that this has to be maintained by hand in every workflow, and that a client editing the workflow can remove it without knowing what it was for, he wrote:
Yeah, the API route’s way cleaner at scale. Tbh, needing a few runs for baseline is a fair tradeoff for not touching every workflow. u/BP041, r/n8n, 30 August 2026
In the same week another reader identified a real flaw in the open-source monitor: it treated a node the client had deliberately deleted as a silent failure rather than an edit. That was fixed the same day, the objection is now a test case, and he is credited by name in the repository.
This has a direct consequence for how a workflow estate should be watched. A dashboard that counts executions by status — so many succeeded, so many warned, so many failed — is reading the same status field that this behaviour makes wrong. The run whose branch quietly stopped firing is counted among the successes, because successful is genuinely what n8n recorded. Catching it means comparing what a workflow produced against what it normally produces, rather than trusting what it reported.
The same reading found a defect in someone else’s codebase two days later. ODS, an open-source stack that installs and manages n8n workflows, told the user a workflow was active whether or not activation had actually succeeded — and its test suite could not tell the difference, because the test mocked activation as succeeding unconditionally. A contributor opened a fix within hours. The untestable part took a second review to surface, and the test was written the same hour it was raised. The pull request is still open at the time of writing. The exchange is public.
All of it is public and checkable, which is the point.
The audit establishes what is failing today. The monitor ensures that you, rather than your client, are the first to know next time.
One thing worth knowing before deciding when rather than whether: n8n prunes execution history on a retention schedule, and the audit reads that history. A workflow that has been producing nothing for three weeks, on an instance keeping fourteen days, has already lost the record of when it started and what normal looked like before it did. The failure is still findable. The evidence of how long it has been costing you is not.
Raising the retention setting is the right move and worth doing whether or not you engage me. It only takes effect forward, though: nothing restores history that has already been pruned, and on n8n Cloud the ceiling is set by your plan rather than by you.
One week · fixed scope
$500one-time
The report is yours regardless of whether the engagement continues. It names specific workflows and is written to be handed directly to another engineer.
Buy the auditExternal · read-only
$99per instance / month
Running outside your instance is not the point on its own — any uptime check does that. It matters because a watchdog built as an n8n workflow stops when the instance does, and silence from a dead watchdog is indistinguishable from good news. Read-only; it never writes to your instance. Output assertions need a few weeks of runs before they can distinguish a normal count from a low one, so the value compounds from the day it starts observing rather than the day you need it.
Book a 20-minute callThis problem is multiplied across every account you manage, and your clients discover it before you do.
The monitor is available white-label: your name on the alerts, your dashboard, your margin. It can be billed as part of your managed service, and a single agreement covers every client on your books.
20 client instances · 4 currently silent · 0 alerts raised
I build and run automated systems that have to work unattended — scheduled agents, API pipelines, and a video production pipeline that renders and publishes on its own.
I built the monitoring because my own scheduled jobs were finishing with empty output and nothing was telling me. I fixed it for myself first.
This is a single-person practice. There is no account manager and no sales process: you work directly with me, and I answer my own email.
Why not just use n8n's error workflow?
It only fires on errors, and every failure above is a non-error. And if the instance is down or a worker is OOM-killed, there's nothing left running to send you anything.
Can't I build this myself?
Yes — several people on the n8n forum have, independently. That's how I know the problem is real. Building it takes a weekend; maintaining it takes indefinitely, and it is not the product you are in business to sell.
Do you need access to my data?
No. Read-only API access. The monitor looks at execution metadata and result counts, never the contents.
What if the audit finds nothing?
You've paid $500 to learn your automations are sound, in writing. For a system doing work you depend on, that's a reasonable outcome.
One week, $500, and a written report that is yours regardless of what follows.