Po11y: monitoring and visibility for n8n CE

Tips & Tricks
1

On github I’ve released Po11y, a dashboard and monitoring service for n8n. I quickly ran into the limits of n8n CE and wanted better insight into my workflows - what runs, what fails, and how things connect.

Po11y is a simple self-hosted dashboard with a docker-compose setup that brings up n8n, Postgres, Grafana, and Prometheus. It pulls information from the n8n API, includes the n8n Grafana dashboards, and builds a live map of your workflows. This became useful to me once I got multiple interlinked workflows with different triggers. Workflow outputs and form triggers can be surfaced directly in the dashboard. Alerting can be hooked up to Slack, Discord, or Telegram, plus a heartbeat ping (e.g. healthchecks.io) so you notice when the monitor itself dies.

git clone https://github.com/labrise-consulting/po11y && cd po11y
./bootstrap.sh

architecture-focus
architecture-focus2880×2000 467 KB

Features:

  • Two modes: bundled stack, or read-only against an existing n8n (API key only, no DB access)
  • Watchdog rules: failing (error count + rate), stale (no success within a per-workflow budget), stuck executions, n8n unreachable
  • Expectation packs: data checks like “orders table must have grown in 26h” - catches runs that finish green but write nothing
  • Architecture map: auto-built from live workflow exports (triggers, sub-workflows, external services), optional AI descriptions through the bundled OmniRoute
  • Execution Health Grafana dashboard via Prometheus exporter (real success rates, worst offenders, time since last success)
  • MCP server: read-only access for AI agents (“why did this workflow fail”)
  • Locked down by default: loopback bind, SELECT-only DB role for Grafana (no credentials or execution payloads), no external bind without auth
  • Yes, mostly AI-written code, so test coverage is high (~650 tests in CI) and automatic PR review is on.
  • MIT licensed, server has zero npm dependencies

Let me know what is missing. I’m also happy to accept PRs.

How do you catch workflows that run fine but do nothing?
2

This fills a very real gap. I especially like the read-only mode for an existing instance and the external heartbeat — a monitor that can disappear silently is just another workflow wearing a tiny supervisor hat :slightly_smiling_face:

Two suggestions that may be useful:

  1. Make stale rules schedule-aware and add a warm-up/grace state after deployment. A workflow scheduled only on weekdays should not start paging people over the weekend, and a freshly deployed monitor should not classify every workflow before it has observed one valid window.

  2. For expectation packs, count at the system boundaries rather than relying only on intermediate n8n item counts. An invariant such as source_seen = destination_committed + quarantined_with_reason can catch the silent-green path where an If or Filter node drops the entire batch before the first internal counter. Otherwise 0 = 0 + 0 balances perfectly while the business process quietly does nothing — mathematically correct, operationally rather unhelpful.

I would also persist the rule version, evaluation window, and evidence used for each alert. That makes an incident reproducible after someone edits a threshold or schedule.

The read-only DB role, external dead-man heartbeat, and explicit warning about payload/credential access are thoughtful safety defaults. Nice release.