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.
Monitoring for n8n & Make
Your automations aren't failing. That's the problem.
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.
Read-only API access
Runs outside your instance
Alerts to Slack or email
invoice-syncevery 15m
Completed
lead-routerevery 5m
Completed
crm-enrichevery 30m
Completed
nightly-exportdaily 02:00
Completed
lead-router stopped checking in 41 minutes ago — and n8n still reports every run as completed.
Failure modes
Four failures your error workflow will never catch
None of these throw. Every one of them is invisible until someone downstream complains. Reproductions and what n8n actually records →
The credential that expired
no HTTP status at allThe token fails at the signing step, before the request ever leaves. Error handling built around status codes never sees a thing.
The node that hangs
still running · foreverIn queue mode both the workflow Timeout and EXECUTIONS_TIMEOUT are ignored. Open as issue #36343 — reported three times, still unfixed.
The run that returns nothing
success · 0 rowsThe upstream source changed shape. Everything downstream processed an empty set — correctly, and pointlessly.
Independently confirmed
The first of those four was tested in public, by people who do not work for me
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.
All of it is public and checkable, which is the point.
Services
Find what is broken, then keep it from going unnoticed
The audit establishes what is failing today. The monitor ensures that you, rather than your client, are the first to know next time.
The Audit
One week · fixed scope
$500one-time
- Every workflow mapped, with what depends on what
- Which ones fail silently today, and exactly how
- Credential expiry exposure, per connection
- Cost per run, and which workflows burn money for no output
- What breaks first, ranked, with what it costs when it does
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 audit
Recurring
The Monitor
External · read-only
$99per instance / month
- Heartbeat per workflow — alerts when a scheduled job stops checking in
- Output assertions — alerts on zero rows, or a count far off its normal
- Credential expiry warnings before the token dies, not after
- Alerts to Slack or email
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 call
For agencies
One instance is an inconvenience. Twenty is your reputation.
This 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
About
Who you will be working with
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.
Common questions
Questions worth asking first
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.
Start here
Find out what's already broken
One week, $500, and a written report that is yours regardless of what follows.