How to monitor n8n workflows manually
A step-by-step DIY setup for catching n8n failures and missed runs with error workflows and a meta-monitoring workflow — and where it breaks down.
Last updated
You can monitor n8n yourself with two pieces: an error workflow that catches failures and posts them to Slack, and a scheduled meta-workflow that queries the executions API to find workflows that have not run recently. This catches most failures but needs per-instance setup.
Steps
1Create an error workflow
Add a workflow whose trigger is the Error Trigger node. In each production workflow's settings, set this workflow as the Error Workflow. It now receives a payload whenever an execution fails.
2Send failures to a channel you actually read
From the error workflow, post to a Slack incoming webhook or a Telegram bot. Include the workflow name, the error message, and a link back to the execution so the alert is actionable on its own.
3Create an API key for meta-monitoring
In n8n, create an API key with read access. You will use it to query the public API from a second workflow. Scope it to read-only where your n8n version supports scopes.
4Build a scheduled meta-monitoring workflow
On a schedule trigger, call GET /api/v1/workflows to list active workflows, then GET /api/v1/executions for each. Compare the newest execution timestamp against how often you expect that workflow to run.
5Alert on silence, not just on errors
If the gap since the last execution exceeds the expected interval plus a grace period, send an alert. This is the step an error workflow cannot do for you, because no execution means no error to catch.
6Repeat for every client instance
Both workflows live inside a single n8n instance, so the whole setup has to be rebuilt and maintained per client. This is where the DIY approach starts to cost more than it saves.
What do you need before you start?
You need admin access to the n8n instance, an API key with read access, and somewhere to receive alerts — a Slack incoming webhook or a Telegram bot both work. If you manage several client instances, you will need all three per instance, which is the main hidden cost of the DIY route.
How do you catch a workflow that never ran?
Query the executions API on a schedule and compare each workflow's most recent execution timestamp against how often it should run. If a workflow runs every 15 minutes and its last execution was 40 minutes ago, it is overdue. Add a grace period so a slow run does not page you. The hard part is knowing the expected interval: it has to be read from cron configuration or learned from history, and re-derived whenever a schedule changes.
Where does the DIY approach break down?
It breaks in three places. The monitor lives inside the instance it monitors, so an instance outage takes the monitor with it. There is no aggregate view across clients, so you are checking ten dashboards instead of one. And when an instance goes down you get one alert per workflow rather than one alert about the instance — which trains you to ignore the channel.