In 14 maanden Growth Partner-werk hebben we 3 incidents gehad. Geen "het draait misschien iets traag", maar echte uitval waar klanten last van hadden. Detection-tijd gemiddeld 18 minuten, fix-tijd gemiddeld 2 uur en 18 minuten. Hier zijn alle drie de cases, met fix en lessen.
Incident 1 — De AI ging plotseling Engelse offertes schrijven
Een klant in de bouw. Workflow: ingekomen offerte-aanvraag wordt door AI uitgewerkt tot concept-offerte, geredigeerd door de eigenaar, dan verzonden. Op een dinsdagochtend in maart 2025: 4 offertes in het Engels uitgegaan. Naar Nederlandse klanten.
Oorzaak
De LLM-provider had een model-update gepushed. Onze system prompt was duidelijk Nederlands, maar het nieuwe model interpreteerde "Schrijf een professionele offerte" iets anders. Geen breaking change in de API, geen versie-bump die zichtbaar was. Gewoon: ander model, andere uitkomst.
Fix
- Locale-test toegevoegd aan de monitoring: na elke run wordt de output gecheckt op Nederlandse markers
- Bij Engelse output: workflow stopt, klant krijgt geen offerte, wij krijgen Slack-melding
- System prompt gehard met expliciet "Antwoord ALTIJD in het Nederlands. Geen Engelse woorden tenzij in productnamen."
Incident 2 — Trigger werd 3 keer afgevuurd
Mei 2025. Klant in de installatie-branche. Workflow: nieuwe inkomende e-mail trigger n8n, n8n maakt taak in Postcoast, stuurt bevestigingsmail terug. Op een vrijdag werden 7 klanten 3x in de wachtrij gezet en kregen ze 3 bevestigingsmails.
Oorzaak
Race condition. De mailbox-trigger draait elke 60 seconden. Bij gelijktijdig binnenkomende mails (een offerte-aanvraag plus een follow-up van diezelfde prospect) werd de polling 3x gestart voordat n8n de eerste run had afgerond. Geen deduplicatie. De fout zat al weken in de workflow, maar werd pas zichtbaar bij volume-piek.
Fix
Deduplicatie-key toegevoegd op basis van Message-ID van de mail. Voor een binnenkomende e-mail check n8n eerst tegen Redis of die ID al verwerkt is. Zo ja: skip. Zo nee: process en sla ID op met een TTL van 7 dagen. Geen duplicaten meer.
Incident 3 — API rate-limit op vrijdagavond
Juli 2025. Een klant in de detailhandel had op vrijdagavond een nieuwsbrief-launch gepland. De workflow synct contact-data van HubSpot naar de mailtool, segmenteert op koopgedrag, en activeert de campagne. Om 19:42 viel het uit: HubSpot rate-limit overschreden. 0 e-mails verzonden.
Oorzaak
Onze workflow deed bij elke contact-update een aparte API-call naar HubSpot. Bij een nieuwsbrief-segment van 8.400 contacten was dat 8.400 calls binnen 4 minuten. HubSpot's burst-limit ligt op 100 calls per 10 seconden. We sloegen er 9x overheen. Geen back-off, geen alerting.
Fix
- Exponentiele back-off: bij rate-limit-respons wacht workflow 2, 4, 8, 16 seconden voor retry
- Batch-API gebruikt waar HubSpot dat aanbiedt — 100 contacten per call ipv 1
- Pre-flight check op aantal calls: workflow blokkeert zichzelf als de geschatte calls boven 80% van de daglimiet komen
- Slack-melding bij 50% van de daglimiet, zodat we kunnen ingrijpen voor het te laat is
Wat we veranderden in onze monitoring-stack
| Voor | Na |
|---|---|
| Slack-melding bij errors | Slack-melding bij errors EN bij anomalies (output-locale, volume, latency) |
| 1 dashboard per klant | 1 dashboard per klant + 1 cross-klant health-overzicht |
| Geen rate-limit-tracking | Rate-limit-tracking op alle externe API's |
| Logs 7 dagen bewaard | Logs 30 dagen bewaard |
"Liever een rommelige melding op vrijdagavond dan maandag een boze klant."
Valentijn — workflow-implementatie
Vuistregel — monitoring is geen luxe
Workflows die productie raken hebben monitoring nodig. Niet "bij gelegenheid". Vanaf dag 1. Onze regel sinds juli 2025: geen workflow gaat live zonder error-handling, deduplicatie, en alerts op zowel falen als anomalie. Dat kost in een Implement Sprint 4-8 uur extra. Het verdient zich elke kwartaal terug bij het eerste niet-incident.