Monitoring n8n workflows: why a “success” status proves nothing
An automation that crashes loudly is not the problem. The problem is the one that stops without a word: customer requests stop reaching your CRM, schedules stop going out, and you find out three weeks later, from a customer. Here is how we monitor our own n8n workflows, and what we learned the hard way.
Failures that make no noise
After years of automations in production, the failures that cost us the most were never spectacular. They all looked alike: nothing turned red, and yet nothing was happening any more.
- A deactivated workflow. Someone switches it off for a test, or an update deactivates it. It no longer runs, so it no longer fails, so nobody is told.
- An expired credential. A Google app left in testing mode loses its authorisation after seven days. A token is revoked by a password change. The workflow runs, the call fails.
- A swallowed error. A step set to continue on error lets an empty response through. The execution ends green. The result does not exist.
- An API that changes. A vendor renames a field. The workflow reads an empty value and writes an incomplete record, every day, without complaint.
- A trigger that never fires. The form on your website is broken: the webhook is never called. n8n has nothing to report, it received nothing.
Why n8n's error workflow is not enough
n8n has a native mechanism: an error workflow, triggered when an execution fails. It is useful and we use it. But it covers only one of the failures above. It does not see a deactivated workflow, since nothing runs. It does not see a swallowed error, since the execution succeeds. It does not see a silent trigger. And it sees nothing at all if the n8n server itself is down.
Serious monitoring looks in three different places.
Level 1: state
The first level answers a simple question: is what should be running actually running? Every five minutes, a monitoring workflow queries the n8n API. It lists the workflows marked as must-stay-active (for us, with a monitored tag) and checks that they are. It lists executions that failed since the last pass. It calls the public addresses that matter, website and forms, and checks that they answer.
The tag matters. Without it, monitoring alerts on every draft and every test, and an alert that rings for nothing is an alert people learn to ignore.
Level 2: result
The second level asks a harder question: does what the workflow was supposed to produce actually exist? A “success” status says the steps ran in sequence, not that the record was created or that the message arrived.
Our rule: every chain ends with a step that reads back the real result. The CRM record is read back after it is created. A Telegram message only counts as sent if Telegram confirms delivery. If the read-back fails, the execution fails, and level 1 sees it.
The test to run on your workflows
Take your most important automation. Deliberately cut its access to the tool it feeds. If the execution still ends green, your workflow lies, and nothing will warn you the day it happens for real.
Level 3: absence
The third level is the one most often forgotten: did what should have happened actually happen? A contact form that receives nothing for five days when it usually gets three requests a day is probably not a coincidence. A morning report that never went out is a failure, even if no execution failed.
Hence a principle we apply everywhere: an expected message always goes out, even when there is nothing to say. Our daily summary sends “nothing to report” rather than staying quiet. That way silence keeps its meaning: it means something is broken.
Free 30-minute audit
We look at your real processes and tell you what is worth automating, and what is not. Pick a slot →
An alert people actually read
- One alert, then a spaced reminder. An alert on detection, a reminder every hour while the problem lasts, not every five minutes.
- A recovery message. When everything is back, a message says so. Without it, nobody knows whether someone dealt with it.
- The right channel. Not an email lost among a hundred others, but a messenger people really look at, for us Telegram, with the workflow name and the cause in plain words.
Who monitors the monitor?
If the n8n server goes down, the monitoring workflow goes down with it. You need an outside view, even a minimal one: a third-party service that calls your n8n from outside and warns you when the instance stops answering. It is the one check you cannot hand over to n8n itself.
Backups are part of monitoring
One day an n8n database gets corrupted, an update goes wrong, someone deletes a workflow by mistake. Every night our monitoring exports every workflow through the API and sends it somewhere separate from the server. The full database, with its credentials and history, is also backed up at server level. Restoring a workflow then takes five minutes instead of a day of rebuilding from memory.
The checklist
- Every workflow that must stay active carries a tag, and nothing else carries it
- A check every five minutes: deactivated workflows, failed executions, public addresses
- Every chain ends by reading back the real result
- Expected messages go out even when there is nothing to say
- Alert, hourly reminder, recovery message, on a channel people read
- An external check of the n8n instance itself
- A nightly backup of the workflows, off the server
Frequently asked questions
How do I get alerted when an n8n workflow stops?
With a monitoring workflow that queries the n8n API every five minutes: it checks that workflows marked as must-stay-active are active, lists failed executions and alerts on a messenger people read, such as Telegram. n8n's native error workflow is not enough because it does not see a deactivated workflow.
Is n8n's error workflow enough to monitor automations?
No. It only fires when an execution fails. It does not detect a deactivated workflow, an error ignored by a step set to continue, a trigger that no longer receives anything, or a stopped n8n server.
Why can an n8n execution succeed without producing anything?
Because a “success” status only means the steps ran in sequence. A step set to continue on error, or an API returning an empty response, lets the execution end green. Every chain should end with a step that reads back the real result.
How do I back up n8n workflows?
Export every workflow through the n8n API each night to storage separate from the server. The full database, which also holds credentials and history, should additionally be backed up at server level.
Read next
n8n monitoringThis monitoring, installed on your n8n in one hour, €19 excl. VAT per month. Where to start automating your businessThe method to pick the right first task. Notion for running a small businessOne database per object, not one table per team.Running an n8n instance nobody watches? We install this monitoring on your instance in one hour, test it in front of you, and hand it over. No set-up fee.