Een n8n-workflow die omzet, klantdata of support raakt, mag niet alleen “groen lijken” in de editor. Je wilt weten wanneer executions falen, wanneer de queue oploopt, wanneer webhooks trager worden en wanneer de server zelf volloopt. Dat is het verschil tussen hobby-automatisering en productiebeheer.
Voor self-hosted n8n is de praktische basis: n8n metrics aanzetten, Prometheus laten scrapen, Grafana gebruiken voor dashboards en je serverlaag bewaken met CloudWatch, Hetzner monitoring, Uptime Kuma of een vergelijkbare tool. Gebruik de bredere n8n monitoring en logging gids als hub; deze pagina gaat specifiek over de Grafana/CloudWatch-inrichting.
De 5 metrics die je als eerste moet zien
Meet niet alles tegelijk. Begin met signalen waar je ook echt op kunt handelen.
| Metric | Waarom hij telt | Actie bij afwijking |
|---|---|---|
| Gefaalde executions | Directe workflowkwaliteit | Check error node, credentials, API-responses |
| Queue waiting/active | Worker-capaciteit en bottlenecks | Meer workers, traagste workflows onderzoeken |
| Workflowduur | API-latency, retries en zware code | Timeouts, batching en parallelisatie nalopen |
| CPU/geheugen/disk | Hoststabiliteit | Prune executions, database en servercapaciteit checken |
| Webhook statuscodes | Inkomende productie-events | Auth, HMAC, rate limits en upstream bron controleren |
Prometheus metrics in n8n aanzetten
Volgens de officiële n8n-documentatie is de `/metrics` endpoint standaard uitgeschakeld. Voor self-hosted zet je hem aan met `N8N_METRICS=true`. In queue mode wil je meestal ook queue metrics opnemen, omdat workerproblemen anders te laat zichtbaar worden.
N8N_METRICS=true
N8N_METRICS_INCLUDE_QUEUE_METRICS=true
N8N_METRICS_QUEUE_METRICS_INTERVAL=20Zet die endpoint niet open op het publieke internet. Scrape intern via je Docker-netwerk, VPN of private subnet. Als je n8n net hebt opgezet, check dan ook de n8n hosting en installatie service; een goede monitoringstack begint bij een voorspelbare serverconfiguratie.
Grafana: bouw een dashboard dat incidenten verkort
Een bruikbaar Grafana-dashboard heeft minder panelen dan je denkt. Zet bovenaan één rij met “kan ik nu veilig slapen?”: failed executions, queue waiting, p95 workflowduur, CPU, memory en disk. Daaronder pas trends per workflow of worker.
Voor teams die met n8n task runners werken, hoort daar een extra paneel bij: code-executions die langer duren dan verwacht. Veel productieproblemen zitten niet in de trigger, maar in een Code node die meer data verwerkt dan bedoeld.
CloudWatch of VPS-monitoring: niet hetzelfde als n8n metrics
CloudWatch ziet vooral je infrastructuur: CPU, memory, disk, network en eventueel containerlogs. Dat is nuttig, maar het vertelt niet welke workflow faalt. Combineer daarom hostmetrics met n8n-executiondata. Bij een piek in CPU wil je direct kunnen zien welke workflow tegelijk langer ging draaien.
Gebruik CloudWatch vooral als je n8n op AWS draait. Draai je op een VPS, dan is een combinatie van Prometheus, Node Exporter en Uptime Kuma vaak eenvoudiger. De keuze is minder belangrijk dan de discipline: elke alert moet een eigenaar, drempel en eerste actie hebben.
Alerts die niet irriteren
Slechte monitoring stuurt te veel meldingen. Goede monitoring stuurt weinig meldingen, maar wel op tijd. Een losse gefaalde execution is vaak geen incident. Tien gefaalde executions in vijf minuten voor dezelfde klantflow is dat wel.
- Alert op herhaalde failures per workflow, niet alleen op één error.
- Alert op queue waiting die langer dan enkele minuten oploopt.
- Alert op diskgebruik boven 80%, zeker als executions lang bewaard blijven.
- Alert op webhook 401/403-pieken; dat wijst vaak op verlopen credentials of verkeerde signing.
- Alert op workflows die veel langer duren dan hun normale p95.
Voor webhookbeveiliging hoort monitoring samen te werken met verificatie. Lees daarvoor de gids over HMAC-signatures bij n8n webhooks.
Wanneer is dit niet de moeite waard?
Voor een persoonlijke workflow die één keer per dag een spreadsheet vult, is een complete Grafana-stack overdreven. Zet dan logging en simpele uptime-monitoring aan. Voor workflows met klantdata, betalingen, leadopvolging of productieprocessen is monitoring geen luxe. Dan wil je incidenten zien voordat iemand op Slack vraagt waarom er niets gebeurt.
De praktische route: eerst goede hosting, daarna n8n metrics, daarna Grafana, daarna pas fine-tuning. Combineer dit met error handling en retries en met de n8n security best practices. Monitoring zonder foutafhandeling vertelt alleen sneller dat iets stuk is.