Your automations aren't failing. That's the problem.

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.

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.

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.