Ran Fine
Manual checking works until about the fourth client. After that the question stops being whether a workflow is broken and becomes which of forty you looked at this week, and whether the client believes you looked at all.
This page is about the operational shape of running automations for other people: how to watch an instance you do not own, and how to make the watching visible to whoever is paying for it. It is written for the person who gets the call when nothing arrived.
The technical detail behind each check lives on three other pages, linked where relevant. What follows is the part that only matters when the instances belong to somebody else.
From outside, through the public API, with a read-only key. Nothing installed, no nodes added to any workflow, nothing running inside the instance.
The reason is not tidiness. A watcher built as a workflow shares the scheduler it is supposed to be watching. When that scheduler stops, the watcher stops with it, and its silence is indistinguishable from everything being fine. The same applies to an error workflow, which cannot fire for a run that never started, and to a dashboard fed by the instance it is describing.
Read-only also matters commercially. A client is being asked to hand a key to a supplier. "It can read execution history and nothing else" is a sentence their security person can approve without a meeting, and it means a mistake on your side cannot damage their system.
Because monitoring that works is indistinguishable from nothing happening. From where the client sits they are paying every month and receiving silence, which is exactly what they would receive if you did nothing.
An agency owner described the outcome precisely in a public thread on r/n8n: the first client he bundled monitoring into cancelled in month two, because from where he sat he was paying for nothing to happen. What changed it was one line a month with the numbers in it. Uptime percentages, he said, got no reaction at all.
This is worth taking seriously rather than treating as a client being unreasonable. The value of a check that finds nothing is real and invisible, and invisible value gets cut at renewal. Making it visible is not marketing, it is the difference between the service surviving and not.
Counts the client recognises, and one line about anything that changed. Per workflow: how many times it ran, how many items it produced, how many needed a human, and any node added or removed since the workflow was last approved.
Last 30 days, in your units:
- invoice-sync: 412 runs, 18,340 items, 3 needed a human.
- lead-router: 8,640 runs, 8,640 items, 0 needed a human.
Changed since you last approved it: added 'Slack alert'; removed 'Send email'.
No percentages. "412 orders processed and 3 that needed a human" is a sentence a client can act on. "99.8% uptime" is not, because nobody on their side knows what the missing fraction cost them, and a number nobody can interpret reads as filler.
The change line does more work than it looks. It is how a client renaming a field, or adding a node to their own workflow, becomes a sentence in a report instead of an incident three weeks later. It also quietly documents that somebody is looking.
Two honesty rules make the report trustworthy rather than decorative. Report a shorter window than requested when the data does not reach back far enough, rather than presenting a partial month as a whole one. And count pruned execution data as unknown and say so, never as zero, because n8n ageing out history is not a workflow producing nothing.
Credentials, upstream API shapes, and clients editing their own workflows. None of the three raise an error at the moment they happen, and all three scale with the number of clients rather than the number of workflows.
That scaling is why the fifth client feels harder than the first four together.
An OAuth token expires and the failure happens at the signing step, before any request goes out. Error handling built around HTTP responses never sees it, because no HTTP exchange took place.
Across an estate this is a calendar problem, not an incident. Every client's tokens expire on their own schedule, and the schedule is invisible until one of them lapses.
A field is renamed, a number arrives where text used to, or a rate-limited API returns 200 with an empty array. The workflow completes and the data quietly stops being right.
The estate-level version is worse than the single-client one. One vendor change breaks every client using that integration at the same moment, and you find out from whichever client happens to look first. Watching the shape of what each node emits is what turns that into one alert rather than four separate phone calls.
Somebody on the client side adds a node, disables one to test something and forgets, or renames a field that another workflow depends on. Nothing is broken from n8n's point of view.
You are accountable for a system you no longer entirely control. Comparing the current node list against the one you last approved is the cheapest possible defence, and it produces the line in the monthly report that clients respond to most.
Whether the data is correct. Every check described here compares a run against that workflow's own history, so a change that moves every record at once is invisible to all of it: the counts are right, the expected values are present, and the history agrees with the wrong answer.
Catching that needs a known-good value from outside the run, which in practice means a person checking a handful of records on a schedule. It is written up in full on the output monitoring page, including why I do not have an automated answer to it.
Worth saying plainly on a page aimed at agencies: this is a young service and I would rather you hear the limits from me than find them at a client. If you want to test the reasoning before trusting any of it, the audit is one instance and one week.
Start with one client instance. A fixed-fee audit: one week, read-only, a written report naming which of their workflows fail silently today and what breaks first.
There is a full sample, run against my own production stack and published unedited, including the five silent failures it found there.
Read the sample auditThe checks and the report described here are implemented and open source: github.com/moneywithjjcom-del/ranfine-. Everything reads execution history through the public API with a read-only key.
The quotations are from public threads on r/n8n and are linked above. The operators are described rather than named, because they were talking to each other rather than writing marketing copy for me.
Related reading: why a workflow stops running while it still says active, four ways a workflow reports success and does nothing, and how to catch a run that produces the wrong output.