How to monitor n8n workflows

What "monitoring" actually means for an n8n stack

Monitoring an n8n instance is not the same as watching CPU on the machine that runs it. The interesting failures aren't infrastructure failures. A healthy server can run zero successful workflows for weeks before anyone notices. What you actually need to see is the state of each workflow: did it run when it was supposed to, did it succeed, what changed since last week, who owns it, and what other workflows depend on it.

Most consultants we've talked to start with a Notion page, move to a Slack channel, and end up with a half-finished Google Sheet six months later. The pattern always breaks at the same place: the consultant takes on a second or third client and the manual stitching stops scaling.

The native options inside n8n

1. Error workflows

n8n supports per-workflow error workflows: you build a workflow that fires when another one errors, and you wire it up either globally or per-flow. It's the canonical answer in the community forum.

Error workflows are useful and underused. Their limits show up when you scale across clients: you have to opt every workflow in (or set a default and remember which clients have it set), the handler itself can fail silently, and they only catch thrownerrors. They don't catch the workflow that quietly stopped firing because its schedule trigger lost a credential, or the one that's technically active but hasn't executed in 47 days.

2. The Executions view

n8n's built-in executions list is the source of truth for what ran. It works well when you're looking at one workflow on one instance. It's not designed to answer questions like “across all my clients, which workflows have an error rate over 5% this month?” or “which workflows haven't run at all since the last release?”

3. The n8n REST API

The API is the foundation everything else builds on. You can list workflows, fetch execution history, pull node configs, and get recent errors. If you're technical and patient, you can build a monitoring layer in Grafana or Datadog on top of it. Most consultants are technical but not patient — building observability for someone else's stack is not what you charge for.

DIY patterns and where they fall down

• Cron-driven uptime checks hitting a webhook in the workflow. Catches outright failures. Misses staleness, missing dependencies, ownership, and node-level errors.
• Slack notifications from the error workflow. Beats nothing. Tends to become alert noise the moment a webhook target goes flaky, and rarely reaches the client.
• Spreadsheet of workflows + owner. The right instinct. Breaks the first time a client hires their own ops person and starts adding workflows without telling you.
• Grafana on the n8n DB. Powerful, requires self-hosted access, and assumes you have time to design dashboards. Most retainers don't make this hour-math work.

The five things every monitoring layer should answer

1. Is this workflow actually running?Not “is it enabled in the UI” — has it executed when expected?
2. What was the last execution result? And how often does it fail in a rolling 30-day window?
3. What does this workflow do, in plain English? Especially the ones you inherited. A short summary saves an hour per workflow during onboarding.
4. What else depends on this workflow? The Execute Workflow chain. The shared credentials. The clients that overlap.
5. Who owns it? A workflow with no owner is a workflow nobody will fix.

What WorkflowRadar does about it

We built WorkflowRadar because we kept rebuilding the same monitoring layer for our own clients. It connects to each client's n8n instance via the API, syncs hourly, and gives you one screen per client that answers all five of the above. It also generates the white-label PDF report your retainer renewal conversation deserves.

Sign up free to start monitoring your first n8n instance — paid plans add multi-client workspaces, scheduled reports, and AI diagnosis.