Hi all,
I look after a production n8n instance with a couple of dozen live workflows. A few months ago a sub-workflow was left unpublished for about five hours. Every call to it failed and 25 payment records were marked as failed. The parent workflow reported success the whole time, because its error branch did exactly what it was built to do. Nobody noticed for two days.
After that I went through the whole instance and found more of the same:
- A weekly workflow had failed on every run for three weeks. It had no error workflow, so nobody was told.
- More than a third of the live workflows had no working failure path.
- Some error workflows were set in the UI and still dead. One pointed at itself, one pointed at a workflow that was never published, and one was blocked by the target’s caller policy. n8n accepts all three settings without complaint.
So I built a workflow that checks for these every morning. It’s in the template library now:
What it checks (through the n8n API, read-only):
- Failed executions in the lookback window
- Schedules that should have fired and didn’t
- Workflows with no working failure path, including the three “set but dead” cases above
- Execute Workflow calls that point to an unpublished or blocked sub-workflow
Two choices that keep it readable:
- It emails only when something is wrong, plus an optional weekly all-clear so you know it’s still running. A missed schedule is reported once, not every day.
- Anything it can’t evaluate (raw cron expressions, for example) is reported as unverifiable, never as OK.
Setup is an n8n API key and a Gmail credential. You can swap Gmail for Slack, Teams or SMTP. If you only want to watch part of the instance, scope it with tags; the workflows you leave out are listed in the digest footer.
One thing it can’t see: a job that ran on time but read stale data from another job. That still needs a person who knows what the workflow is supposed to mean.
What silent failures have you hit that this wouldn’t catch? I’d like to add checks.
Niko