A client's n8n workflow broke silently — here's how I catch it now

The worst n8n failures I've had running automations for clients weren't the loud ones. A node that throws a red error is easy — you see it, you fix it. The ones that cost me sleep were the silent failures: a workflow quietly stops doing its job, everything looks fine, and I find out days later from an annoyed client.

If you run n8n for anyone but yourself, you know the feeling. Here's how I stopped being the last to know.

Why silent failures are the dangerous ones

n8n is great at telling you when an execution errors. It is not great at telling you when something changed about the shapeof your automation. There's no notification when:

• someone edits a workflow and quietly breaks a downstream step,
• a workflow gets deactivated and simply stops running,
• a credential expires and every run starts failing,
• or the whole instance goes quiet because the box fell over.

None of those throw an obvious error in your face. They surface downstream — usually when a customer, a client, or your own boss notices before you do.

What I tried first (and why it didn't hold)

My first instinct was discipline: export workflow JSON regularly, keep a folder of backups, eyeball the executions list every morning. That works for about a week. Across a dozen workflows and several clients, "I'll check it manually" quietly becomes "I haven't checked it in a month." And a folder of dated .jsonfiles doesn't actually tell you what changed — you'd have to diff them by hand, and raw n8n exports are noisy (node positions move, timestamps churn).

The setup I use now

The thing that finally worked was to stop relying on myself remembering, and put something outside n8n that watches it for me. Four pieces:

• Snapshot every change automatically. Every time a workflow changes, capture it — no manual export to forget.
• Diff it in plain English. Not raw JSON: "HTTP Request node — parameters changed; 1 node added (Slack)." Ignore noise like a node being dragged around.
• Alert on the things that matter — a change, a failure spike, a deactivation, or the instance going offline — to Slack/Telegram/Discord.
• Keep a rollback history so when something does break, you can restore the last known-good version instead of rebuilding from memory.

The key shift is that you find out from a tool, immediately — not from a client, three days later.

You can try the diff piece right now

If you just want to see what changed between two versions of a workflow, you don't need any of the above — paste two exports into the free n8n workflow diff tool. It's in-browser, no signup, nothing uploaded. It's the same diff engine I use in the full setup.

And if you want the whole thing — automatic snapshots, alerts, offline detection, rollback — that's what I built Keel for. It runs a lightweight agent next to your n8n; your API key and execution data never leave your box, only redacted metadata does. Free on one instance if you want to kick the tires.