6 september 2026 · Team Driftwork · 1 min leestijd
Fouten afvangen in n8n: vier instellingen die tellen
n8n heeft goede foutafhandeling ingebouwd, maar niet standaard aan. De vier instellingen die het verschil maken tussen stil falen en weten.
Een workflow die op je scherm groen wordt is niet hetzelfde als een workflow die betrouwbaar draait. Dit zijn de vier dingen die wij bij elke productieworkflow instellen, en die standaard niet aan staan.
1. Een aparte foutworkflow
n8n kan bij elke mislukte uitvoering een tweede workflow starten. Daar zet je één ding in: een bericht naar de plek waar iemand het ziet, met de naam van de workflow, de foutmelding en een link naar de uitvoering.
Bouw hem één keer en koppel hem aan al je workflows. Zonder deze stap staat een fout alleen in de uitvoeringslijst, en die opent niemand uit zichzelf.
Belangrijk: laat de foutworkflow zelf niets ingewikkelds doen. Een foutmelder die zelf kan falen is geen foutmelder.
2. Opnieuw proberen, maar niet overal
Veel storingen zijn tijdelijk: een API die kortstondig niet reageert, een limiet die net overschreden is. Voor dat soort stappen zet je in de node-instellingen een paar pogingen aan met een wachttijd ertussen.
Maar niet overal. Bij een stap die iets aanmaakt of verstuurt, kan opnieuw proberen betekenen dat je hetzelfde twee keer doet. Zet herhalen dus aan bij ophalen en opzoeken, en wees terughoudend bij aanmaken, versturen en betalen.
3. Doorgaan bij fouten, bewust gekozen
Elke node heeft de optie om bij een fout toch door te gaan. Dat is precies wat je wilt bij een lijst van honderd items waarvan er één rammelt: de andere negenennegentig moeten gewoon verwerkt worden.
Het is precies wat je niet wilt bij een enkele stap in een keten, want dan loopt de workflow door met lege gegevens en schrijft hij die netjes weg. Dat is de stille fout waar niemand achter komt.
Vuistregel: aanzetten binnen een lus over items, uitlaten in een rechte lijn van stappen.
4. Weten dat hij gedraaid heeft
De ondergewaardeerde: een workflow die helemaal niet start, geeft geen foutmelding. Een uitgeschakelde trigger, een verlopen inlog of een verwijderde webhook levert stilte op.
Zet daarom een controle die de andere kant op kijkt: als de dagelijkse verwerking om tien uur nog niet gedraaid heeft, dan een melding. Dat is tien minuten werk en het is de enige manier om stilte te horen.
En verder
Zet in elke productieworkflow een notitie met wie hem gebouwd heeft, wat hij doet en wat er gebeurt als hij een dag niet draait. Bij een storing op een vrijdagmiddag is dat het eerste wat iemand zoekt.