The branch that skips
step SKIPPED · run COMPLETEDA 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.
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 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.
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.
The upstream source changed shape. Everything downstream processed an empty set — correctly, and pointlessly.
The audit establishes what is failing today. The monitor ensures that you, rather than your client, are the first to know next time.
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
The monitor runs outside your instance, so it continues reporting even when n8n itself is unavailable. It never writes to your instance.
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.