Most n8n monitoring stops at execution errors. That’s the easy case — n8n catches it, your error workflow fires, you get a Slack message.
The failures that actually cost you clients are the ones n8n marks as successful.
Case 1 — The credential that dies silently
Google OAuth in Testing mode expires after 7 days. When it does, n8n throws Unable to sign without access token — but this happens at the signing step, before any HTTP request goes out. No status code. No execution error. If you’re routing alerts on HTTP failures, this one falls straight through.
Case 2 — The node that “succeeds” with an error inside
Any node with onError: continueRegularOutput will complete and mark the execution green. The actual error object sits inside runData for that specific node. Top-level status says success. Your client’s data never moved.
Catching both requires checking two things — execution status AND walking resultData.runData per node looking for error keys. The second one catches more than the first.
Both of these are invisible until a client calls asking why their data hasn’t updated in three days.
What I built for this:
I built Okum — a dashboard for n8n agencies managing workflows across multiple clients. Connect your n8n server in 2 minutes. Okum scans your full execution history on day one, finds silent failures, expired credentials, and inactive workflows before your clients notice anything.
When something breaks, it tells you exactly whose fault it is — your workflow, the client’s credential, or an external API. So you stop debugging blind and start responding with answers.
If you’re managing more than 3-4 client workflows and still checking n8n manually — this is built for you. Free to try: okum.cloud
“Happy to walk anyone through it — just reply here or DM me.”