n8n monitoring: what to watch, and what n8n will not tell you
A practical guide to monitoring n8n in production — what is worth watching, what the built-in options do and do not cover, a checklist you can work through today, and how OutcomeGuard approaches the same problem.
What to monitor in n8n
Execution status is the easiest thing to watch and the least informative. These are the signals that matter in roughly the order they bite.
Did it run at all
For every scheduled workflow, compare the newest execution against the interval the trigger declares, in the trigger's own timezone. A missing run produces no error and no log line.
Did it error
Failed, crashed and cancelled executions. The one signal n8n surfaces well, and the one you probably already have covered.
Did it do anything
Item counts per run. A success that moved zero items is the single most common quiet outage.
Where did it end
The last node executed on a successful run. When that moves earlier, items are leaving through a branch that does nothing.
How long did it take
Duration against the workflow's own normal. A collapse usually means empty input; a spike usually means a struggling dependency.
Is the configuration the same
Whether the definition changed and whether the workflow is still active. Most “it stopped working” incidents start with an edit.
Did the outcome actually happen
The row in the database, the file in storage, the field in the CRM. The only signal that answers the question your stakeholders are really asking.
The built-in options, and where they stop
n8n gives you real tools here. It is worth knowing precisely what each one covers before you rely on it.
| Built-in option | What it does | Where it stops |
|---|---|---|
| The execution list | Shows every recent execution with status, start time and duration, and lets you open a run and inspect the data at each node. | Nobody reads it daily, it cannot show you a run that never started, and zero items looks identical to a full result until you open it. |
| Error Workflow | Runs a workflow of your choice whenever a workflow fails, which makes alerting on thrown errors straightforward. | It only fires on thrown errors. A workflow that never triggers, returns nothing, or stops one node early never calls it. |
| Stop and Error node | Lets you raise a deliberate failure on a path that should never carry items, which is what turns a quiet branch into a real error. | You have to predict the quiet path and add the node yourself, in every workflow, and keep doing it as the workflows change. |
| Retry on fail and Continue On Fail | Handles transient problems inside a node, so a flaky API does not fail a whole run. | Continue On Fail can convert a real failure into a successful execution carrying an error as data — a silent failure by construction. |
| Logs and metrics on self-hosted | Container logs, and queue and worker metrics, tell you about the health of the n8n instance itself. | They describe the platform, not the business outcome. A perfectly healthy instance can be running a workflow that has achieved nothing for a week. |
| A heartbeat or dead-man's switch | A workflow pings an external service at the end of each run, and the service alerts when a ping is late. | It proves the run reached the ping node. It says nothing about whether the data was correct, complete or written anywhere. |
A checklist you can work through today
None of this needs a new tool. It needs an afternoon.
- List every active workflow and write down, for each, what “working” means in one sentence.
- For each scheduled workflow, note the expected interval and the timezone the trigger is evaluated in.
- Set an Error Workflow on every workflow that matters, and confirm it actually notifies a human.
- Find every IF and Filter node with an unconnected output, and connect it to a Stop and Error node or a notification.
- After every node that fetches data, add a check on the item count and route zero somewhere visible.
- Write down the normal item count and duration for each important workflow, so a deviation is recognisable.
- Review Continue On Fail settings and remove the ones that are hiding real failures.
- Decide what the deadline is for each daily job — the time by which the work must be done — and whether anyone would notice if it passed.
- For the two or three workflows that cost the most when they break, add a downstream check that the target actually changed.
How OutcomeGuard covers the same ground
The checklist above is maintainable for five workflows. OutcomeGuard exists because it is not maintainable for fifty.
- It learns a baseline per workflow from that workflow's own executions: cadence, duration, item counts and the node successful runs usually end on.
- It parses cron and interval triggers with their timezone, so a missed run is detected at the time it should have happened.
- It detects failures, silent failures, missed runs, empty output, volume and latency anomalies, auth and downstream errors, and configuration drift.
- Outcome Contracts let you state the result you expect — ran, succeeded, at least N items, finished in time, downstream confirmed — and a workflow is healthy only when all of it holds.
- Findings are deduplicated into incidents with a cooldown, so one outage is one email.
- Every finding carries evidence, a timestamp, a confidence score and a reason, and a workflow with too little history is reported as insufficient data rather than as an anomaly.
Frequently asked questions
- Does n8n have built-in monitoring?
- n8n shows an execution list and can run an Error Workflow when a workflow fails, and self-hosted instances expose logs and queue metrics. That covers hard failures and platform health. It does not tell you that a scheduled run never happened, that a successful run moved zero items, or that the downstream target was never updated.
- How do I get alerted when an n8n workflow fails?
- Set an Error Workflow in the workflow's settings and have it send an email or a chat message. Add Stop and Error nodes on the paths that should never carry items, otherwise quiet failures never reach the Error Workflow at all.
- Why does my n8n workflow show success but do nothing?
- Usually an unconnected IF or Filter branch, a source returning zero items, an expired credential answered with an empty response, or Continue On Fail turning an error into data. The execution is genuinely successful by n8n's definition: no node threw.
- How can I tell that a scheduled workflow stopped running?
- Compare the newest execution against the interval the trigger declares, in the trigger's timezone. If the gap is larger than the interval plus a little slack, nothing ran. Common causes are a deactivated workflow, a timezone mismatch, a cron expression that does not mean what it looks like, and an instance restart.
- Does monitoring n8n require write access to the instance?
- No. Everything described here can be read through the n8n public REST API with a read-only key. OutcomeGuard never writes to your workflows, credentials or settings.
- What is the difference between execution monitoring and outcome verification?
- Execution monitoring answers did it run and did it error. Outcome verification answers did the job get done: the run happened by the deadline, it succeeded, it carried enough items, it finished in time, and the target system actually changed. A workflow can pass the first and fail the second for weeks without anybody noticing.
- Does this work with n8n Cloud as well as self-hosted?
- Both. OutcomeGuard uses the n8n public REST API, which n8n Cloud and self-hosted instances both expose. A self-hosted instance needs to be reachable from the internet for the hosted scan.