n8n monitoring tools: what each approach actually catches
There are five ways to monitor n8n, from the execution list you already have to a dedicated service. They do not catch the same failures. This page compares them by failure type, so you can pick the smallest setup that covers the ways your workflows really break.
The short answer
n8n's built-in Error Workflow catches thrown errors and nothing else. A free community template can catch scheduled workflows that stop firing. Heartbeat services confirm a run reached the ping. Infrastructure observability (Prometheus, Grafana, SigNoz, Dynatrace) tells you the instance is healthy, not that the work happened. Only a monitor that reads execution history and compares it with each workflow's own baseline can tell you that a run reported success but did not do its job. OutcomeGuard is one such monitor; it is read-only and does not add nodes to your workflows.
Last updated: September 12, 2026
Six ways an n8n workflow fails, and what has to be watched to see each one
Comparing tools by feature list hides the only question that matters: which failures will you find out about, and how soon. These are the six patterns that recur in the n8n community forum and in our own scans.
| Failure | What n8n shows | What has to be watched |
|---|---|---|
| Hard error | A red execution with an error message | The execution's status — the only case n8n reports on its own |
| Missed run | Nothing. No execution exists | The schedule: when the next run was due, in the trigger's timezone, and whether it happened |
| Silent failure (stopped early) | A green execution that ended at an earlier node than usual | The node each successful run ends on, compared with the workflow's history |
| Empty output | A green execution with 0 items | Item counts against how often zero is normal for that workflow |
| Stale output | Green executions that keep producing the same result | Whether the destination is actually changing (a row count, a file date, a last-updated field) |
| Outcome not met | Green execution; the business result did not happen | A rule about the result: at least N items, finished within X, reached node Y by the deadline |
Approach 1: what n8n gives you out of the box
The execution list, the Error Workflow (with the Error Trigger node), Stop and Error, retry-on-fail and continue-on-fail. Free, already installed, and worth configuring before anything else.
- Catches: hard errors, immediately, via the Error Workflow.
- Misses: everything that does not throw. A workflow that never triggers, returns nothing, or stops one node early never calls the Error Workflow.
- Cost of coverage: you can convert quiet paths into real errors by adding Stop and Error nodes on the branches that should never carry items — but you must predict each quiet path, in every workflow, and keep doing it as workflows change.
- Continue On Fail turns a real failure into a green execution carrying an error as data: a silent failure by construction. Use it deliberately or not at all.
Approach 2: a free n8n template that checks schedules
The n8n template “Monitor scheduled workflow health in n8n with automatic trigger checks” (community template 13290, checked 2026-09-12) is a workflow that runs inside your own n8n once a day. It lists active workflows through the n8n API, parses each Schedule Trigger's cron expression, compares the last execution with the allowed gap (48 hours for daily jobs, 8 days for weekly, 35 days for monthly) and raises an error listing overdue workflows, so your Error Workflow can alert on it.
- Catches: scheduled and polling workflows that stopped firing, within a day.
- Misses: silent failures, empty output, stale output, outcomes; webhook-triggered workflows, which have no schedule to check; and it cannot see itself — if the monitoring workflow is what stopped, nothing reports it.
- Best for: a self-hosted instance with a handful of daily jobs where a one-day detection delay is acceptable.
This is the honest baseline any paid monitor has to beat. If your only problem is “my nightly job stopped and I found out a week later”, install the template first and see whether that is enough.
Approach 3: heartbeat and cron monitors
Generic dead-man's-switch services (the Healthchecks or Cronitor pattern): a workflow ends with an HTTP Request node that pings a URL, and the service alerts when the ping is late.
- Catches: missed runs and runs that died before the last node, usually within minutes.
- Misses: everything about the data. A run that fetched zero rows, wrote nothing and then pinged the heartbeat looks perfect.
- Cost of coverage: one node per workflow, and the ping node itself becomes something that can be deleted, disconnected or left on a branch that never executes.
See what your instance would report
The free health check reads one n8n instance through the API, compares each workflow with its own history and lists missed runs, silent failures and empty successes. Read-only; the API key is discarded after the scan.
Approach 4: infrastructure observability
Self-hosted n8n can expose Prometheus metrics, and OpenTelemetry integrations exist for platforms such as SigNoz and Dynatrace. Grafana dashboards over queue depth, worker count, memory and execution counts are the standard for operating the n8n instance itself.
- Catches: the instance being down, workers stuck, memory pressure, a sudden drop in total executions.
- Misses: whether any individual workflow did its job. A perfectly healthy instance can run a workflow that has achieved nothing for a week, and the dashboards stay green.
- Best for: teams already running Prometheus or an observability platform, who need it anyway for the rest of their stack. It is a complement to workflow-level monitoring, not a substitute.
Approach 5: n8n-specific monitoring services
A small category appeared in 2025–2026: services built only for n8n that read execution history and judge each workflow against its own behaviour. As of 2026-09-12 the ones we could verify from their public sites include Watchflow, Midwatch and OutcomeGuard; several smaller tools exist. Prices change, so they are not repeated here — each vendor publishes them.
- Watchflow
- Positions around missed runs, silent failures and stale output, and publishes an official n8n template. Its setup adds a step to the monitored workflow, which is the same trade-off as a heartbeat: the monitor is inside the thing it monitors.
- Midwatch
- Read-only monitoring for n8n (and Cloudflare Workers). Lists silent failures, config drift, zombie runs, cadence, hard failures and reachability as its detections; email, Slack and Telegram alerts; 14-day trial.
- OutcomeGuard (this site)
- Read-only monitoring for n8n through an API key, with no node added to any workflow. Learns a baseline per workflow (excluding the newest runs so an incident cannot pollute its own baseline), then detects missed runs from the parsed schedule, silent failures from the terminal node, empty output against the workflow's own zero-rate, stale output, volume and latency anomalies, and Outcome Contracts you write as rules about the result. Email alerts. Free for 3 workflows; Solo $19, Pro $39, Agency $99 per month. Launched September 2026 — there are no customer reviews to point you to yet.
What separates the three is not the list of detections, which converges, but where the monitor sits: inside the workflow (a node you add) or outside it (an API key that reads). Inside means faster confirmation of “the run reached this point” and one more thing that can silently break. Outside means nothing to maintain in the workflow and the ability to judge a run by its history and its output.
Which one to choose
- One instance, a few daily jobs, no budget
- Configure the Error Workflow, add Stop and Error on quiet branches, and install the free template. Accept a one-day delay on missed runs.
- Webhook- or event-driven workflows
- The template cannot help (no schedule). You need something that learns the normal cadence and alerts when it goes quiet — a heartbeat, or a service that reads execution history.
- Workflows whose “success” has burned you before
- Zero rows written, a filter that stopped matching, a branch that stopped carrying items: only history-based detection (terminal node, item counts, duration) sees these. Run the free scan below on your own instance and see whether anything is already in that state.
- Agencies running client instances
- Look for per-client workspaces and a report you can forward. OutcomeGuard's Agency plan and Midwatch's Agency plan both target this.
- You already run Prometheus and Grafana
- Keep them for the instance. Add workflow-level monitoring for the outcomes; the two answer different questions.
Where OutcomeGuard is not the right choice
- You need instance metrics (CPU, memory, queue depth). We do not collect them; use Prometheus or your observability platform.
- You want everything inside n8n with no external service. The free template plus Stop and Error nodes is the right answer.
- You need Slack or Telegram alerts today. OutcomeGuard sends email; other channels are on the roadmap, not shipped.
- Your workflows are manual-only and run when a person clicks. There is no cadence to learn and little to verify.
Frequently asked questions
- Does n8n have built-in monitoring?
- It has an execution list, an Error Workflow that runs when a workflow throws, and metrics for self-hosted instances. It does not detect a scheduled workflow that stopped firing, a run that ended early without an error, or a run that produced nothing.
- Is a free n8n monitoring template enough?
- For scheduled workflows on one instance, often yes: template 13290 checks schedules once a day and alerts through your Error Workflow. It cannot see webhook workflows, silent failures or empty output, and it cannot report on itself.
- What is the difference between execution monitoring and outcome monitoring?
- Execution monitoring asks whether the workflow ran and whether it threw. Outcome monitoring asks whether the intended result happened: the rows were written, the emails went out, the file changed. A run can pass the first and fail the second without any error.
- Do n8n monitoring services need access to my workflows?
- It depends on the approach. Node-based services need you to edit each workflow. Read-only services like OutcomeGuard use an n8n API key with read access to workflows and executions and never modify anything.
- How quickly is a missed run detected?
- The free template checks once a day. OutcomeGuard polls every 5 minutes on the Free plan, every 2 on Solo and every minute on Pro and Agency, and raises a missed run once the schedule's deadline plus a grace period has passed.
See what your instance would report
The free health check reads one n8n instance through the API, compares each workflow with its own history and lists missed runs, silent failures and empty successes. Read-only; the API key is discarded after the scan.