n8n Monitoring Guide 2026: Uptime, Failed Workflows & Alerts

A failed n8n workflow doesn't throw an alert by default — it just stops, and unless you built in notifications, you find out when someone notices the downstream effect (an unsent invoice, a missed Slack notification, a stale spreadsheet). Real monitoring for n8n means layering three things: workflow-level error alerts, instance uptime, and a heartbeat check.

How to Monitor n8n in Production

1. Wire Up the Error Trigger Node

n8n's built-in Error Trigger node fires whenever any workflow in your instance fails. Route it to a Slack channel or email so every failure surfaces in real time, rather than relying on someone stumbling onto it.

2. Add a Heartbeat Workflow

Build a simple scheduled workflow that pings an external monitoring endpoint every few minutes. If the heartbeat stops arriving, you know n8n itself has stopped processing — a broader signal than any single workflow's error.

3. Monitor Instance Uptime Directly

For self-hosted n8n, set up an HTTP health check against your instance URL, plus server-level monitoring for CPU, memory, and database connectivity. For n8n Cloud, track status.n8n.io.

4. Consolidate with API Status Check

API Status Check tracks n8n Cloud status alongside the rest of your stack and sends instant Slack, email, or PagerDuty alerts on change.

What to Track

• Workflow error rate: Route all Error Trigger events to one channel and watch for spikes.
• Instance uptime: HTTP health checks for self-hosted, status page tracking for Cloud.
• Credential expiry: Many "failures" are actually expired OAuth tokens on connected nodes — track these separately from true outages.
• Heartbeat gaps: A missing scheduled heartbeat is the clearest signal that n8n itself has stopped running, not just one workflow.

Conclusion

n8n doesn't alert you by default when something breaks — you have to build that in. Combine the Error Trigger node, a heartbeat workflow, and instance-level uptime monitoring for full coverage.