Error alerts in n8n that people actually read
An alert channel that posts every failure gets muted within a week. Useful alerting sends fewer messages: one when something breaks, one when it recovers, and one when a workflow quietly stops doing its job.
One shared error workflow
Create one workflow that starts with an Error Trigger node, and select it as the error workflow in the settings of every production workflow. When an automatic (production) execution fails, n8n runs it with the workflow name and ID, the error message, the last node that ran and, when executions are saved, a link to the failed execution. Manual test runs do not trigger it.
Keeping it shared means the format, the channel and the rules live in one place. Write every alert the same way:
- What broke: the workflow name and the node that failed.
- Why: the error message, shortened.
- Where to look: the execution link.
- Who acts: the team or role that owns the workflow, from a small lookup table.
Use the Stop and Error node to fail a workflow on purpose when a business rule is broken, so those cases go through the same alerts.
Alert on state change, not on every failure
A workflow that runs every five minutes against an API that is down fails twelve times an hour. Nobody needs twelve messages. Keep the last known state of each workflow (working or failing) in a small table: the data tables in recent n8n versions, a database table or a spreadsheet.
- On failure, the error workflow reads the state. If it was “working”, it sets it to “failing” and sends the alert. If it was already “failing”, it only increases a counter.
- On success, the last step of the production workflow writes “working”. If the previous state was “failing”, it sends a short “recovered” message saying how long it was down.
- If a workflow stays failing, send one reminder after an agreed interval instead of repeating every failure.
Before alerting at all, turn on Retry On Fail for nodes that call external services, so a brief timeout is retried rather than reported.
Empty-run detection
Some failures are silent: the execution succeeds but processes nothing, because a token expired and the API returns an empty list, a filter changed or the source stopped sending. The error workflow never runs.
Count the items after the step that fetches data. If a node returns no items, the nodes after it do not run, so turn on Always Output Data for that node. It then outputs a single empty item, so check for real data rather than the item count. If there is no data where there normally is (for example, a daily import that always has rows), end the run with a Stop and Error node; it then goes through the shared error workflow and its state rules.
Decide per workflow what “unusually empty” means. For sources that are legitimately empty on some days, alert only after several empty runs in a row.
Missed-schedule checks
If the n8n instance is down, the workflow was deactivated or the schedule never fired, there is no failed execution and no error alert. Only a check that expects a signal can catch it.
- At the end of each scheduled workflow, record a heartbeat: the time of the last successful run.
- A separate check compares each heartbeat with the expected interval plus a grace period, and alerts once when a workflow is overdue.
- Run that check outside the n8n instance it watches, for example with a heartbeat monitoring service or a scheduled job on another server; a check inside the same instance stops when the instance does. Self-hosted instances can also be watched through their health check endpoint.
Who reads the alerts
- Send alerts to one channel the owning team already watches, not to a personal inbox.
- Write them so someone who is not a developer can act: what stopped, what it affects, where to look.
- Review the alerts monthly: an alert nobody acted on should be changed or removed.