n8n Monitoring Dashboard: Build One or Use a Tool

An n8n monitoring dashboard is a single view of your instance's health: execution volume, success and error rate, per-workflow run duration, worker queue depth, and — for AI workflows — LLM cost per workflow. n8n exposes some of this through a Prometheus metrics endpoint you can chart in Grafana, which is enough for infrastructure health. But two of the things you most want, per-workflow LLM cost and detection of runs that finished green but wrong, aren't in those metrics at all. This guide covers what belongs on the dashboard, how to build the DIY version, where it runs out, and the managed alternative.

What belongs on an n8n monitoring dashboard

A useful dashboard answers three questions: is the instance healthy, are workflows succeeding, and what is it costing? Map each to a metric. Execution volume and queue depth tell you about load and whether workers are keeping up. Success rate and error rate tell you about reliability. Per-workflow run duration surfaces the slow or degrading workflow before users notice. And for anything with an LLM node, cost per workflow is the number that stops a quiet bill from tripling unnoticed.

The trap is stopping at the metrics that are easy to get. Uptime and execution counts are the easy ones and they look reassuring, but they say nothing about whether a workflow produced correct output. A dashboard that's all green while a workflow silently writes empty records is worse than no dashboard, because it tells you everything is fine.

The DIY route: Prometheus + Grafana

n8n can expose a Prometheus metrics endpoint. Set the environment variable N8N_METRICS=true (self-hosted; check the metrics options in your version's docs, as the flags and defaults have changed across releases) and n8n serves counters and gauges at /metrics — process health, event-loop lag, and n8n-specific counters like workflows started, succeeded, and failed. From there the standard stack is Prometheus to scrape and store the series, and Grafana to chart them.

The outline: point Prometheus at your n8n /metrics endpoint on a short scrape interval, add Prometheus as a data source in Grafana, then build panels — execution rate from the started counter, success rate as succeeded over started, error rate as failed over started, and queue depth from the worker gauge if you run queue mode. For per-workflow duration and per-workflow error rate you'll want the metrics labelled by workflow (available in recent versions), otherwise you only get instance-wide totals. This gets you a genuinely useful infrastructure and reliability dashboard for free.

Where DIY runs out

Two hard limits and one soft one. First, LLM cost is not in the Prometheus metrics — n8n never sums the token usage that LLM nodes return, so no scrape gives you cost per workflow. To chart it you'd have to capture each call's tokens and price them yourself, which is a separate pipeline entirely (the approach in n8n cost tracking). Second, none of these metrics detect silent failures: a failed counter only moves on a thrown error, so a run that returns a 200 with a bad body still counts as a success on your dashboard.

The soft limit is maintenance. A Prometheus and Grafana stack is infrastructure you now own — scrape configs, retention, dashboard JSON, and alert rules that drift as n8n's metric names change between versions. That's fine if you already run this stack for other services. If you stood it up only for n8n, the upkeep often outweighs the visibility, and the two metrics you most needed still aren't there.

Native vs DIY vs managed, side by side

Here's how each metric maps across the options — what you can read straight from n8n, what a Grafana build gives you, and what a managed tool adds:

The managed alternative

If you don't want to run Prometheus and Grafana — or you do, but still need per-workflow cost and silent-failure detection — a managed tool gives you the dashboard without the build. Obsivara connects to n8n read-only, with no logging nodes to add and no proxy in your request path, and derives execution volume, success and error rate, per-workflow duration, queue depth, and per-workflow LLM cost from your executions and llm_call events. It also does the two things the metrics endpoint can't: attribute cost per workflow and per model, and flag runs that finished green but wrong.

There are no dashboards to build or maintain — the views and alerts exist out of the box, and they track each workflow against its own baseline so you're alerted on drift rather than staring at panels. Start with a free 48-hour audit to see what your instance actually looks like on a real dashboard, or read the complete guide to monitoring n8n workflows for the full picture across health, errors, and cost.