How to Monitor n8n Workflows

n8n gives you better native error handling than most automation platforms, so monitoring it is mostly about covering the two things Error Trigger cannot see: a workflow that stops being triggered, and an n8n instance that is not running.

If you self-host, the second one is the important one and it is easy to overlook.

Start with an error workflow

Build one workflow that starts with an Error Trigger node, then point every other workflow at it via Settings, Error Workflow. One error workflow can serve your whole instance.

The Error Trigger node receives the failing workflow's name, the execution ID, the node that failed and the error message, which is enough to make the alert actionable rather than just loud.

Set the HTTP Request node's URL to your monitor's ingest endpoint and add the X-API-KEY header. Give it a short timeout so a slow monitoring endpoint never becomes the reason your error workflow itself fails.

Add a success heartbeat, separately

Error Trigger fires on failure. It says nothing when a workflow silently stops being triggered, which happens when a webhook registration is lost, a polling credential expires, or someone deactivates the workflow and forgets.

Add an HTTP Request node as the final node of each important workflow. Because n8n halts execution at a failing node by default, a node in last position only runs on a complete pass.

If a workflow has multiple terminal branches, put the ping on the branch that represents genuine completion rather than on all of them, or you will get a ping from a run that took the early-exit path.

The self-hosting problem

Error workflows and heartbeats both run inside n8n. If the n8n container stops, the database it depends on fails, or the host runs out of disk, none of them fire. Your monitoring dies with the thing it was monitoring.

Two checks fix this and they take a few minutes. Point an external uptime monitor at your n8n instance's health endpoint, and treat the heartbeat interval as the backstop that notices the whole instance went quiet.

Queue mode adds a second failure surface. The main process can be perfectly healthy while every worker is down, in which case executions queue up and never run. A heartbeat on a frequently-triggered workflow catches that; an uptime check on the main process does not.

Execution data retention will hide the evidence

Self-hosted n8n prunes execution history according to EXECUTIONS_DATA_MAX_AGE, which defaults to 336 hours. If you are debugging a failure from three weeks ago, the execution may simply be gone.

For workflows that handle anything financial or customer-facing, either raise that value or make the alert carry enough detail to be useful on its own, which is the better habit anyway.

Related guides

The same pattern applied to other platforms is in Make.com scenarios and Zapier automations.