Een n8n-workflow is pas beheersbaar wanneer je niet alleen ziet dát hij draait, maar ook of de juiste bedrijfsuitkomst op tijd ontstaat. Goede n8n-monitoring combineert daarom vijf onderdelen: health checks, herleidbare logs, betekenisvolle alerts, passend bewaarbeleid en een getest herstelpad met een duidelijke eigenaar.
Meer over het platform zelf lees je op onze pagina over n8n.
De verraderlijkste storing is vaak niet de rode execution. Lastiger is de groene run waarna in het doelsysteem toch een order, factuur of klantrecord ontbreekt. Dan heb je technisch bewijs dat n8n iets heeft gedaan, maar nog geen bewijs dat het proces is gelukt. Precies daar begint monitoring die ook buiten het technische team bruikbaar is.
Belangrijkste inzichten
Wat je vooral moet onthouden
- Bewaak de n8n-instance, workflow-uitvoeringen én de bedrijfsuitkomst; een bereikbare server bewijst nog niet dat een order of klantrecord goed is verwerkt.
- Laat iedere melding minimaal verwijzen naar workflow, execution-ID, foutcategorie, omgeving, tijd en eigenaar, maar kopieer geen secrets of volledige persoonsgegevens naar chat of e-mail.
- Maak herstel veilig vóórdat je retries automatiseert. Dezelfde invoer mag bij een tweede poging niet ongemerkt een tweede factuur, taak of e-mail veroorzaken.
Wat moet n8n-monitoring in productie bewaken?
Productiemonitoring werkt in lagen. Als je alleen naar groene executions kijkt, mis je stille fouten: een workflow kan technisch slagen terwijl het doelsysteem een incompleet record bevat. Wie alleen de server controleert, ziet evenmin dat een wachtrij oploopt of een dagelijkse run niet is gestart.
Gebruik daarom vier bewakingslagen:
- Beschikbaarheid: is de n8n-instance bereikbaar en klaar om verkeer te verwerken?
- Uitvoering: starten en eindigen de verwachte workflows, en hoeveel lopen vast, wachten of mislukken?
- Bedrijfsuitkomst: is het verwachte resultaat werkelijk ontstaan in CRM, boekhouding, mailbox of database?
- Beheerbaarheid: zijn logs, executiedata, opslag, wachtrijen en credentials zó ingericht dat een beheerder het incident kan onderzoeken en herstellen?
De derde laag is vaak het belangrijkst. Een HTTP 200 of groene node zegt alleen iets over die technische stap. Leg daarom per proces één of meer controlepunten vast, zoals “aantal ontvangen orders = aantal verwerkte orders + verklaarde uitzonderingen”.
Wil je eerst de flow zelf goed opbouwen? Begin dan bij een betrouwbare n8n-workflow opzetten. Dit artikel pakt het beheer ná livegang op.
Begin met signalen en eigenaarschap
Een bruikbare melding beantwoordt drie vragen: wat wijkt af, wie beslist wat er moet gebeuren en welk bewijs is nodig om het incident te sluiten? Start daarom niet met een dashboard vol metingen, maar met de processen die niet stil of verkeerd mogen lopen.
Maak per proces een klein signalenregister:
| Signaal | Wat het bewijst | Eigenaar | Eerste actie | Bewijs van herstel |
|---|---|---|---|---|
| Readiness-check faalt | n8n is niet klaar voor verkeer | technisch beheer | instance en databaseverbinding onderzoeken | readiness geeft weer 200 en een test-run slaagt |
| Verwachte run ontbreekt | trigger of planning heeft niet geleverd | workflowbeheer | trigger, publicatiestatus en laatste execution controleren | gemiste periode is aantoonbaar verwerkt |
| Execution mislukt | een technische route is gestopt | workflowbeheer | fout classificeren en context openen | veilige retry of handmatige afhandeling is vastgelegd |
| Bedrijfsuitkomst ontbreekt | procesdoel is niet bereikt | proceseigenaar | bron en doelsysteem vergelijken | doelrecord of actie is gecontroleerd aanwezig |
| Foutpercentage loopt op | terugkerende verstoring of gewijzigde invoer | technisch en functioneel eigenaar | groeperen op workflow, node en fouttype | oorzaak verholpen en achterstand verwerkt |
Werk met een functionele én een technische eigenaar. De technische eigenaar kan vaststellen waarom een API-call faalt. De functionele eigenaar beslist of een order opnieuw mag worden verwerkt, een klant moet worden geïnformeerd of een financiële handeling menselijke goedkeuring vereist.
Health checks: bereikbaar is niet hetzelfde als gereed
n8n biedt verschillende endpoints voor self-hosted monitoring. Volgens de officiële documentatie over n8n-monitoring geeft /healthz aan dat de instance bereikbaar is. Deze check bewijst niet dat de databaseverbinding gezond is. /healthz/readiness geeft pas 200 wanneer de database verbonden en gemigreerd is en de instance gereed is voor verkeer.
Gebruik de endpoints dus voor verschillende vragen:
/healthz: reageert het n8n-proces?/healthz/readiness: kan de instance inclusief databaseverwerking verkeer aannemen?/metrics: welke operationele status en tellers meldt de instance?
Het metrics-endpoint is volgens n8n niet beschikbaar op n8n Cloud en staat bij self-hosting standaard uit. Je activeert het met N8N_METRICS=true. De health check van de hoofdinstance staat altijd aan; voor queue workers moet je de worker-check apart activeren met QUEUE_HEALTH_CHECK_ACTIVE=true.
Beheer je meerdere workers, omgevingen en rollen, leg deze controles dan vast als onderdeel van de bredere n8n Enterprise-architectuur. Zo blijft monitoring gekoppeld aan deployment, eigenaarschap en herstel.
Beveilig metrics op infrastructuurniveau. Publiceer zo’n endpoint niet onbeperkt op internet en behandel labels of foutcontext als operationele informatie. Controleer na iedere configuratiewijziging bovendien de actuele n8n-documentatie en test eerst buiten productie.
Logging: maak iedere fout herleidbaar
Logs krijgen waarde wanneer je vanuit een alert naar de juiste uitvoering kunt navigeren. De n8n-handleiding voor logging beschrijft onder meer executionId, workflowId, node-type en nodenaam als nuttige context. Leg daarnaast omgeving, foutcategorie en tijd vast. Gebruik een eigen correlatie- of event-ID als dezelfde gebeurtenis meerdere systemen passeert.
Voor self-hosted n8n kun je onder meer instellen:
N8N_LOG_LEVELvoor bijvoorbeelderror,warn,infoofdebug;N8N_LOG_OUTPUTvoor console, bestand of beide;N8N_LOG_FILE_LOCATIONvoor het logbestand;N8N_LOG_FILE_SIZE_MAXenN8N_LOG_FILE_COUNT_MAXvoor logrotatie.
De n8n-documentatie noemt 16 MB als standaard maximale bestandsgrootte en 100 bestanden als standaard aantal. Zie dat niet als automatisch passend beleid. Bepaal bewaartermijn en volume op basis van incidentonderzoek, privacy, opslagcapaciteit en interne afspraken. Zet debug niet onbeperkt aan in productie: meer detail kan onderzoek helpen, maar veroorzaakt ook meer data en ruis.
Log geen API-sleutels, authenticatieheaders of complete gevoelige payloads. Laat een melding liever verwijzen naar beveiligde broninformatie dan die informatie te kopiëren naar e-mail of chat. De n8n-securitychecklist helpt om logging samen met credentials, toegang en hosting te beoordelen.
Alerts zonder alarmmoeheid
Niet ieder foutbericht verdient direct dezelfde pieper. Als iedere losse mislukking een urgent chatbericht veroorzaakt, leert het team meldingen negeren. Classificeer alerts op bedrijfsimpact en tijdsgevoeligheid.
| Niveau | Voorbeeld | Reactie |
|---|---|---|
| Kritiek | productieflow ligt stil, financiële of klantkritieke route mogelijk geraakt | direct naar dienstdoende eigenaar, met gecontroleerde stop- of terugvalroute |
| Waarschuwing | fouttrend loopt op of achterstand nadert afgesproken grens | binnen afgesproken venster onderzoeken en bundelen per oorzaak |
| Informatief | losse herstelbare fout zonder directe impact | registreren voor trendanalyse; geen directe onderbreking |
Kies drempels niet omdat een voorbeeldconfiguratie een mooi rond getal gebruikt. Baseer ze op het normale volume, het afgesproken verwerkingsvenster en de impact van te late of onjuiste verwerking. Een nachtelijke rapportage mag mogelijk langer wachten dan een orderbevestiging.
Bundel herhaalde fouten op workflow en foutcategorie, voorkom dubbele meldingen en leg escalatie vast. Iedere alert bevat bij voorkeur:
- omgeving en workflow;
- execution-ID of directe beveiligde verwijzing;
- foutcategorie en eerste waarneming;
- aantal of trend, niet een onbegrensde stroom identieke berichten;
- functionele en technische eigenaar;
- runbook of concrete eerste controle.
Executiedata doelgericht bewaren
n8n slaat executiongegevens in de database op. De officiële n8n-documentatie over execution data waarschuwt dat die database groeit en adviseert alleen de benodigde data te bewaren en pruning te gebruiken. Je kunt bijvoorbeeld fouten wel bewaren en succesvolle uitvoeringen niet, afhankelijk van je onderzoeks- en bewijsbehoefte.
Pruning staat volgens de huidige documentatie standaard aan. De standaard leeftijdsgrens is 336 uur, oftewel 14 dagen, en de standaard volumelimiet is 10.000 afgeronde executions. Lopende, wachtende en nieuwe executions worden niet door deze pruning verwijderd; geannoteerde executions worden bewaard. Dit zijn productdefaults, geen universeel bewaarbeleid.
Kies per workflow bewust:
- welke succesvolle runs bewijswaarde hebben;
- welke foutdata nodig zijn voor diagnose;
- hoe lang een proces achteraf herleidbaar moet blijven;
- welke persoonsgegevens niet in executiondata horen;
- waar incidentnotities en besluiten worden bewaard.
Logs en executiondata hebben verschillende functies. Logs ondersteunen zoeken, trendanalyse en infrastructuuronderzoek. Executiondata toont de route en node-uitvoer van een concrete run. Bewaar niet automatisch alles dubbel.
Herstelpaden veilig ontwerpen
Een alert zonder herstelpad verplaatst het probleem naar een inbox. Leg vóór livegang vast hoe je de flow pauzeert, een achterstand isoleert, een mislukte run onderzoekt en de bedrijfsuitkomst controleert.
De n8n-pagina over alle executions beschrijft filters op workflow, status en startmoment. Een mislukte execution kan opnieuw worden uitgevoerd met de momenteel opgeslagen workflow of met de oorspronkelijke workflow. Controleer vóór iedere retry of de hoofdactie idempotent is: dezelfde invoer mag niet tot een tweede onbedoelde bedrijfsactie leiden.
- Classificeer de fout. Is hij tijdelijk, permanent of nog onbekend?
- Controleer de bedrijfsstatus. Heeft het doelsysteem de actie misschien al uitgevoerd voordat de timeout ontstond?
- Isoleer onzekere items. Zet ze in een gecontroleerde uitzonderingslijst; laat ze niet eindeloos rondgaan.
- Herstel veilig. Retry alleen bij een herhaalbare route of na menselijke goedkeuring.
- Controleer de uitkomst. Vergelijk bron, execution en doelsysteem.
- Sluit met bewijs. Noteer oorzaak, actie, resterende achterstand en preventieve wijziging.
Voor foutlogica binnen één workflow—zoals een centrale Error Trigger, fallback, begrensde retry en Stop And Error—blijft foutafhandeling binnen een n8n-workflow de inhoudelijke eigenaar. Productiemonitoring bepaalt juist hoe je meerdere flows en hun bedrijfsuitkomsten bewaakt, prioriteert en beheerst.
Test je monitoring vóór productie
Test niet alleen of een alert technisch aankomt. Test of de juiste persoon hem begrijpt en veilig kan handelen. n8n ondersteunt een workflowbrede error workflow die start met de Error Trigger. Volgens de documentatie over graceful error handling kun je met Stop And Error bewust een fout veroorzaken en zo het foutpad testen.
Voer minstens deze oefeningen uit in een veilige testomgeving:
- forceer een gecontroleerde workflowfout en controleer alert, context en eigenaar;
- simuleer ongeldige invoer en bevestig dat die niet automatisch wordt geretryd;
- bied hetzelfde event tweemaal aan en controleer dat geen dubbele bedrijfsactie ontstaat;
- laat een afhankelijk systeem gecontroleerd een timeout of foutrespons geven;
- controleer wat er gebeurt als de database of worker niet gereed is zonder productiegegevens te riskeren;
- doorloop pauzeren, handmatig verwerken, hervatten en nacontrole;
- verifieer dat secrets en onnodige persoonsgegevens niet in de melding staan.
Noteer per test de verwachte melding, beslisser, herstelactie en sluitbewijs. Een groene test betekent pas iets wanneer ook het doelsysteem klopt.
Praktische monitoringmatrix
Onderstaande matrix is een startpunt, geen universele norm. Pas frequentie en grenswaarden aan op het procesvolume en de foutimpact.
| Controle | Bron | Frequentie of trigger | Eigenaar | Herstelactie | Sluitbewijs |
|---|---|---|---|---|---|
| instance bereikbaar | /healthz | externe periodieke check | technisch beheer | proces en infrastructuur onderzoeken | stabiele respons en test-run |
| instance gereed | /healthz/readiness | periodiek en na deployment | technisch beheer | database/migratie controleren | readiness 200 |
| workerstatus | worker health en metrics | periodiek | technisch beheer | queue en workercapaciteit onderzoeken | achterstand daalt gecontroleerd |
| mislukte executions | executionlijst of centrale foutflow | direct of gebundeld | workflowbeheer | classificeren, isoleren, veilig herstellen | uitvoering en doelsysteem gecontroleerd |
| ontbrekende verwachte run | eigen planningscontrole | na afgesproken tijdvenster | proceseigenaar | trigger en bron onderzoeken | gemiste periode verwerkt |
| ontbrekende bedrijfsuitkomst | vergelijking bron–doel | per batch of controlemoment | proceseigenaar | uitzonderingenlijst en handmatige route | aantallen sluiten of afwijkingen verklaard |
| log- en datagroei | bestand, database en retentiecontrole | periodiek | technisch beheer | rotatie/pruning aanpassen | groei binnen vastgesteld beleid |
Begin klein: kies één bedrijfskritische flow, vul de matrix in en voer een gecontroleerde storingsoefening uit. Schaal het patroon daarna uit naar workflows met vergelijkbare impact.
Monitoring wordt pas echt nuttig wanneer iemand ook eigenaar is van de opvolging. Leg daarom vast wie een melding beoordeelt, wie een proces mag stilzetten en wie na herstel controleert of het doelsysteem weer klopt. Onze gids over workflow management werkt die bredere afspraken voor eigenaarschap, wijzigingen en incidenten uit. Een dashboard zonder die afspraken is vooral een duur nachtlampje.
Wil je de signalen, alerts en herstelroutes van een bestaande omgeving laten beoordelen? Bekijk dan hoe de n8n-specialisten van Flowstate implementatie, hardening, monitoring en overdracht aanpakken.
Veelgestelde vragen over n8n-monitoring
Wat is het verschil tussen /healthz en /healthz/readiness?
/healthz controleert of de n8n-instance bereikbaar is, maar bewijst niet dat de database gezond is. /healthz/readiness geeft pas 200 wanneer de database verbonden en gemigreerd is en de instance klaar is voor verkeer.
Is het metrics-endpoint beschikbaar op n8n Cloud?
Nee. De officiële n8n-documentatie vermeldt dat /metrics niet beschikbaar is op n8n Cloud. Bij self-hosting staat het standaard uit en activeer je het met N8N_METRICS=true.
Hoe lang moet ik n8n-executiedata bewaren?
Daar is geen universele termijn voor. Bepaal de periode op basis van incidentonderzoek, procesbewijs, privacy en opslag. n8n gebruikt momenteel standaard pruning met een leeftijdsgrens van 336 uur en een volumelimiet van 10.000 afgeronde executions, maar je eigen beleid kan strenger of ruimer moeten zijn.
Hoe voorkom ik dubbele verwerking bij een retry?
Gebruik een stabiele event- of idempotency-sleutel en controleer vóór de schrijfactie of de bedrijfsactie al is uitgevoerd. Controleer na een timeout eerst het doelsysteem; een technische foutmelding betekent niet altijd dat de externe actie niet heeft plaatsgevonden.
Wat is het verschil tussen een error workflow en productiemonitoring?
Een error workflow verwerkt fouten uit afzonderlijke n8n-workflows en kan centraal meldingen doorgeven. Productiemonitoring omvat daarnaast beschikbaarheid, trends, ontbrekende runs, bedrijfsuitkomsten, retentie, escalatie, eigenaarschap en herstel over meerdere workflows.
Beeldverantwoording: de geplande redactionele beelden voor dit artikel worden voor Flowstate gegenereerd met AI. Ze verbeelden anonieme werksituaties en zijn geen foto’s van klanten, medewerkers of uitgevoerde projecten.
