You're running n8n in production. You have Uptime Kuma, a healthcheck endpoint, maybe even a Grafana dashboard. You think you're covered.
You're not.
Uptime monitoring tells you your server is alive. It has no idea whether your workflows are actually doing their job. This guide covers what real n8n workflow monitoring looks like and how to set it up.
Why Uptime Monitoring Isn't Enough
When your n8n container is up and /healthz returns 200, everything looks fine. But n8n can be perfectly healthy as a service while your workflows sit completely idle.
A scheduled workflow can miss every execution for a week. No crash. No alert. Just silence. Uptime Kuma will stay green the whole time.
The problem is that uptime monitors measure infrastructure. You need something that measures outcomes.
What You Actually Need to Monitor
A complete n8n monitoring setup covers four things:
1. Execution presence Did the workflow run at all? A scheduled workflow that hasn't executed in 24 hours when it should run every hour is broken, even if no error was logged.
2. Execution success Did it complete without errors? n8n has a built-in Error Trigger node for this, but it only catches workflows that actively fail not ones that silently stop.
3. Credential validity Expired API keys and OAuth tokens cause workflows to fail silently on the first node. You won't know until you check.
4. Activation status Workflows can get deactivated during deployments or config changes. n8n won't re-activate them or tell you they're off.
Option 1: Kuma Push Monitors
Uptime Kuma has a "Push" monitor type that works as a dead man's switch. You add a final HTTP node to each workflow that pings a Kuma URL on success. If the ping doesn't arrive within the expected window, Kuma alerts you.
Pros: Free, self-hosted, works well for simple cases.
Cons: You have to modify every workflow individually. Every new workflow needs a push node added manually. If you forget, that workflow is unmonitored. Doesn't catch workflows that execute but produce wrong results.
Option 2: Canary Workflows
A second n8n instance fires a test workflow into your main instance every 15 minutes and verifies via API that the execution landed in the database within the expected window.
Pros: True end-to-end verification, catches infrastructure-level silent failures.
Cons: You're now maintaining monitoring infrastructure on top of your actual product. Two n8n instances to keep updated, secured, and running. More moving parts, more things to break.
Option 3: External API-Based Monitoring
n8n exposes execution timestamps via its API. An external service can poll that API on a schedule, compare the last execution time against a threshold you set, and alert you when a workflow goes quiet without touching your workflows at all.
Pros: Zero modifications to existing workflows. Auto-imports new workflows. Works across multiple instances. No infrastructure to maintain.
Cons: Requires trusting a third-party service with your n8n API key (read-only access).
Comparison
| Approach | Setup effort | Covers new workflows automatically | Requires workflow changes | Self-hosted | |---|---|---|---|---| | Kuma push monitor | Medium | No | Yes | Yes | | Canary workflow | High | No | No | Yes | | External API monitor | Low | Yes | No | No |
The Recommended Setup
For most self-hosters managing n8n for clients, the pragmatic answer is a combination:
- Error Trigger workflow inside n8n for active failures catches crashes and node errors immediately.
- External silence monitor for scheduled workflows catches the cases where nothing happens at all.
Together they cover both failure modes: the workflow that breaks, and the workflow that disappears.
FlowGuard handles the second part. It connects to your n8n instance via API key (read-only), auto-imports all active workflows, and alerts you when one goes past its silence threshold. Setup takes 60 seconds.
If you manage n8n workflows for clients, FlowGuard is the layer of reliability n8n doesn't ship with. Start monitoring for free no credit card required.