n8n error workflows die zichzelf niet versterken

Je bouwt een workflow. Alles loopt. Totdat je de eerste echte storing krijgt.

Een API die 2 minuten niet reageert.
Een rate limit die ineens harder aantikt dan gisteren.
Of één node die faalt… en daarna nog eens… en daarna ineens je hele systeem meesleept.

Want dit is wat bijna niemand doorheeft:

Error handling is óók een workflow.

En als je ‘m niet goed ontwerpt, doet ‘ie bij fouten precies wat je níét wilt: méér calls, méér pogingen, méér spam, méér failures.

Wat is een error workflow die zichzelf versterkt?

Kort gezegd: een error workflow die bij een fout extra fouten veroorzaakt.

Je herkent het aan dit soort symptomen:

• één storing → tientallen pogingen in korte tijd
• je meldingen exploderen (Slack, mail, tickets)
• dezelfde lead wordt 2× geüpdatet of 2× gemaild
• je loopt ineens tegen rate limits aan “terwijl er niks nieuws gebeurt”

De workflow faalt niet alleen. Hij maakt de situatie erger.

De drie valkuilen waar bijna iedereen intrapt

1. Opnieuw proberen zonder grenzen

Dit is de klassieker: “als het faalt, probeer nog een keer.”
En als het weer faalt… nog een keer.

Zonder limiet, zonder pauze, zonder plan.

Gevolg:

• je verhoogt de belasting precies op het moment dat de andere kant al moeite heeft
• je vergroot de kans op rate limits
• je creëert extra executions en extra betaalde calls

Opnieuw proberen is prima. Maar alleen als je het begrensd en vertraagd doet.

2. Je error workflow doet zelf óók risicovolle dingen

Veel error workflows doen iets als dit:

“Als het faalt → stuur Slack → schrijf iets terug naar CRM → maak ticket → notify iemand”

Klinkt logisch, maar je maakt je error route net zo afhankelijk van externe systemen als je hoofdflow.

Gevolg:

• je error workflow faalt ook
• je krijgt errors op errors
• en je bent alsnog blind, maar nu met extra ruis

Een goede error route is “licht”: eerst het probleem zichtbaar maken, dan pas herstellen.

3. Geen bescherming tegen dubbel uitvoeren

In productie ga je dit soort situaties zien:

• dezelfde gebeurtenis komt 2× binnen (opnieuw afleveren, updates, storingen)
• of jouw “opnieuw proberen” herhaalt een stap die al half gelukt is

Dan krijg je:

• dubbele CRM updates
• dubbele e-mails
• dubbele tickets
• of statussen die heen-en-weer springen

Dit is waarom “opnieuw proberen” bij elke stap opnieuw een keuze, nooit een “default”.

Fail fast vs opnieuw proberen: kies per stap

De fout is denken: “de workflow mag wel/niet opnieuw proberen.”

In werkelijkheid heeft elke stap een ander risicoprofiel.

Wat is fail fast precies?

Fail fast betekent: je stopt direct zodra je ziet dat deze stap niet veilig of niet zinvol is om door te duwen.

Concreet:

• je voert géén vervolgstappen uit die kosten, ruis of schade kunnen veroorzaken
• je maakt de fout zichtbaar (status, tag, melding)
• je parkeert het item voor review of later herstel

Dus: niet “hard crashen”, maar “veilig stoppen”.

Wanneer je bijna altijd fail fast kiest

Kies fail fast als:

• de stap impactvol is (mail versturen, CRM write, payment, delete)
• je niet zeker weet of het al (deels) gelukt is
• de fout wijst op een structureel probleem (validation, permissions, verkeerde input)

Vuistregel: als dubbel uitvoeren schade veroorzaakt, moet je niet blind opnieuw proberen.

Wanneer opnieuw proberen juist wél logisch is

Opnieuw proberen is vooral nuttig als de kans groot is dat het tijdelijk is.

Kies opnieuw proberen als:

• je een timeout ziet
• je een 429/rate limit ziet
• je een 5xx ziet (storing aan de andere kant)
• en de stap is herhaalbaar of “dubbel veilig” gemaakt

Vuistregel: opnieuw proberen werkt als wachten de kans op succes vergroot, en herhalen geen schade aanricht.

De vier bouwblokken van goede error workflows

1. Begrens “opnieuw proberen”

Opnieuw proberen zonder stopconditie is geen strategie, maar een lek.

Maak het simpel:

• max 3 pogingen
• daarna: markeer als “Review nodig” of “Later opnieuw”

Je hoeft niet perfect te zijn. Je hebt alleen grenzen nodig.

2. Vertraag opnieuw proberen

Als het misgaat, is “meteen nog eens” meestal het slechtste idee.

Een korte pauze doet twee dingen:

• je ontlast de andere kant
• je voorkomt dat jij jezelf in rate limits duwt

Wacht liever 30–60 seconden, dan 10 keer achter elkaar opnieuw te falen.

3. Voorkom dubbel melden

Eén fout = één incident.

Als je error workflow elke mislukte poging meldt, maak je notificaties waardeloos. Mensen gaan het negeren. En precies die ene belangrijke fout zie je dan niet meer.

Maak daarom één simpele afspraak:

• één melding per item per periode
• en daarna alleen als er iets wezenlijks verandert (bijv. “nu echt gestopt”)

4. Escaleer met context (niet met paniek)

Het beste alarm is niet alleen luid. Het is bruikbaar.

Wat je wél wilt:

• welk item ging fout (lead/ticket/id)
• welke stap faalde
• wat de foutmelding globaal is
• wat de workflow nu gaat doen (stoppen / opnieuw proberen / later / review)

Wat je níét wilt:

• een dump van alles wat er in de workflow zat
• 12 meldingen met elk een andere variant

Maak je error workflow “licht”

Een goede vuistregel voor error workflows is “doe zo min mogelijk”.

Dus:

• label / markeer / log
• stuur één melding
• stop of parkeer

En pas daarna (optioneel): een herstelactie die je vertrouwt.

Als je error route zelf afhankelijk wordt van 5 externe systemen, dan heb je geen error handling gebouwd. Dan heb je een tweede workflow gebouwd die ook kapot kan gaan.

Voorbeeld dat bijna iedereen herkent

Je flow doet lead-opvolging:

1. Nieuwe lead binnen
2. Verrijking (externe API)
3. CRM update
4. Notificatie naar sales

Dan komt de realiteit: de verrijkings-API geeft 429.

Goede keuze per stap:

• Verrijking: opnieuw proberen met vertraging, max 3 pogingen
• CRM update: fail fast als je niet dubbel veilig kunt updaten
• Notificatie: pas sturen als je zeker weet wat de status is

En je error route?

• zet tag “Review nodig” of “Later opnieuw”
• stuur één melding met lead-id + “verrijking faalde (429), poging 3/3, nu geparkeerd”
• klaar

Geen ticketfabriek. Geen Slack-storm. Geen extra fouten.

Onthoud dit

De belangrijkste punten uit dit artikel op een rij:

• Error handling kan je systeem stabiliseren, of jezelf in een failure-loop trekken.
• Kies fail fast vs opnieuw proberen per stap, niet per workflow.
• Opnieuw proberen is prima, zolang je het begrensd en vertraagd doet.
• Houd je error workflow licht: één melding, duidelijke status, dan pas herstel.
• Bescherm jezelf tegen dubbel uitvoeren, anders wordt “opnieuw proberen” een kosten- en foutenvermenigvuldiger.

Handig voor ChatGPT/Gemini

Wil je met een chatbot brainstormen over ProspectPro integraties met n8n? Dan is het handig als ‘ie weet hoe onze node in elkaar zit. Onze code is volledig openbaar, dus dat is geen enkel probleem. Vraag simpelweg of Chat deze linkjes onderzoekt, en je kan los:

n8n: https://n8n.io/integrations/prospectpro
GitHub: https://github.com/ocjanssen/n8n-nodes-prospectpro
NPM: https://www.npmjs.com/package/@bedrijfsdatanl/n8n-nodes-prospectpro
API docs (community node uses this API): https://docs.prospectpro.nl