No-code workflow vrijgeven voor productie: proefbatch, replay en uitzonderingen testen

Je workflow werkt in testmodus. Iedereen klikt groen. Dan komt productie: een API antwoordt te laat, dezelfde webhook komt twee keer binnen of een update arriveert vóór het record waarop hij hoort te wachten. De flow stopt niet altijd. Soms doet hij precies het verkeerde twee keer.

De dure vraag is daarom niet of je automatisering één voorbeeld kan verwerken. De vraag is of je vóór livegang kunt bewijzen wat er gebeurt bij een timeout, duplicate, replay, gebeurtenis buiten volgorde, onbereikbare API en menselijke uitzondering. Deze gids maakt van die vraag een vrijgaveproef voor n8n, Make en vergelijkbare workflowtools. Een eerste flow met formulier, CRM, Slack en conceptfactuur kan al werken, maar die werkende keten is nog geen bewijs dat retries en replay veilig zijn.

Na afloop heb je een fixture-set, een verwerkingsledger, een uitzonderingsqueue en één meetbare go-live-KPI. Dat is het verschil tussen een demo die werkt en een proces dat je durft los te laten.

Wat je nodig hebt voor een geloofwaardige proefbatch

Een workflow-acceptatietest is een gecontroleerde proef: je voert de gelukkige route uit én injecteert fouten en herhalingen. Per fixture leg je de verwachte eindstand, toegestane side effects, auditstatus, eigenaar en herstelactie vast. De workflow is pas vrijgegeven als alle kritieke fixtures reproduceerbaar slagen en geen uitzonderingen zonder eigenaar achterblijven.

Je hebt zeven bouwstenen nodig. Zet ze klaar vóór je in n8n op Test workflow klikt of in Make een scenario handmatig start.

• Een afgebakende workflowversie. Geef de flow een versienummer, bijvoorbeeld orders-to-invoice v0.9.3, en zet de onderliggende credentials naar een testomgeving. Test nooit met een echte betaalactie, verzendopdracht of verzonden klantmail.
• Een bronhouder en sleutelcontract. Noteer per object welk systeem de waarheid bezit, welke sleutel uniek is en welke versie of wijzigingstijd geldt. Een event_id voorkomt dubbele eventverwerking. Een order_id voorkomt dubbele bedrijfsobjecten. Dat zijn niet altijd dezelfde sleutel.
• Een fixture-set. Maak testrecords die je bewust kunt terugvinden. Neem minstens happy path, timeout, duplicate, out-of-order, replay, onbereikbare API en menselijke uitzondering op. Bewaar payload, verwacht resultaat en test-ID buiten de workflow.
• Een verwerkingsledger. Gebruik bij n8n bijvoorbeeld PostgreSQL of een andere tabel met een unieke combinatie van bron, event-ID en handeling. In Make kan een Data Store dezelfde rol spelen, maar controleer of de sleutel echt uniek is. Bewaar status, attempt, target_id, foutreden, tijdstip en eigenaar. Een losse logregel achteraf is geen deduplicatie.
• Een veilige doelomgeving. Je doel moet echte regels afdwingen. Als je testdatabase dubbele facturen accepteert terwijl productie dat niet mag, test je een andere werkelijkheid. Gebruik dezelfde verplichte velden, unieke indexen en statusovergangen als straks live.
• Een uitzonderingsqueue met naam en deadline. Minimaal: fixture-ID, bron-ID, foutklasse, laatste poging, voorgestelde actie, eigenaar, deadline en bewijslink. Een foutmelding zonder eigenaar is geen proces, maar een vergeten inbox.
• Een rollback- en vrijgavekaart. Leg vast wie de workflow uitzet, welke versie teruggaat, welke berichten blijven staan, hoe je de ledger bewaart en wie het go/no-go-besluit neemt. Voor een eenvoudige flow is dit meestal een halve tot hele dag voorbereiding. Bij geld, voorraad of meerdere bronhouders reken je op een aparte ontwerp- en repetitieronde.

De kosten van de test zitten dus zelden in een extra abonnement. Op 30 september 2026 toont de actuele n8n-prijspagina Cloud Starter voor 20 euro per maand bij jaarlijkse betaling, met 2.500 workflowuitvoeringen en vijf gelijktijdige uitvoeringen. Pro kost 50 euro voor 10.000 uitvoeringen en twintig gelijktijdige uitvoeringen. Make toont op zijn actuele prijspagina een gratis plan met 1.000 credits per maand en een Make-plan van 9 dollar per maand voor 5.000 credits. Bij Make telt elke moduleactie als credit, niet een volledige workflowrun. Die actuele prijzen zijn nuttig voor je testbegroting, maar ze zeggen niets over de kwaliteit van je vrijgaveproef.

Concrete stappen: van fixture-set naar vrijgave

Je geeft een no-code workflow vrij door eerst de verwachte uitkomst per fixture vast te leggen, daarna gecontroleerd fouten te injecteren, elke side effect achter een unieke sleutel te zetten, uitzonderingen aan een mens toe te wijzen en ten slotte een vaste go-live-poort te vullen. Voer de stappen in deze volgorde uit.

1. Bevries de scope en schrijf de verwachte eindstand op

Schrijf niet op dat de workflow “de order verwerkt”. Schrijf op wat dat precies betekent. Voor ORD-1042 kan de eindstand zijn: één order in het doel, één conceptfactuur, één Slack-melding, één ledgerregel met status succeeded en geen open uitzondering. Voor een afgewezen order kan de eindstand juist zijn: geen factuur, wel één queue-item met eigenaar Finance en een deadline van vier werkuren.

Maak per fixture een klein contract met deze kolommen:

Zet deze contracten vast voordat je de flow verandert. Anders maak je achteraf de verwachting passend bij wat de tool toevallig deed. Bij een CRM-migratie werkt dezelfde discipline: een proefbatch met aantallen, relaties en reconciliatie moet eerst verklaard zijn voordat je de route vrijgeeft.

2. Maak zeven fixtures die de werkelijkheid nabootsen

Gebruik niet zeven bijna gelijke klantrecords. Elke fixture moet een ander faalmechanisme openen.

1. Happy path. Eén geldig event levert één correcte doelrecord en alle toegestane vervolgstappen op.
2. Timeout na verzending. De doel-API krijgt de aanvraag wel, maar het antwoord komt te laat. Je moet kunnen aantonen dat een retry de bestaande doelactie herkent.
3. Duplicate. Bied exact hetzelfde event-ID en dezelfde payload twee keer aan, zonder tussentijdse wijziging. De tweede poging mag geen nieuwe side effect maken.
4. Out-of-order. Bied versie 12 vóór versie 11 aan, of stuur een update vóór create. De oude versie mag de actuele eindstand niet overschrijven.
5. Replay na succes. Draai de volledige payload opnieuw nadat de eerste run geslaagd is. Een replay is geen nieuwe zakelijke opdracht.
6. Onbereikbare API. Laat de doelservice tijdens alle toegestane retries niet antwoorden. De workflow moet begrensd stoppen of naar de uitzonderingsqueue gaan, nooit stilzwijgend doorgaan met een lege doel-ID.
7. Menselijke uitzondering. Laat een verplichte waarde ontbreken of laat een vooraf gekozen grens overschrijden. Er komt geen onomkeerbare actie voordat een benoemde eigenaar beslist.

Stripe documenteert dat webhook-events dubbel kunnen worden afgeleverd, maximaal drie dagen automatisch worden herprobeerd en niet in de volgorde van ontstaan hoeven binnen te komen. De documentatie noemt ook handmatig opnieuw versturen tot vijftien dagen via het dashboard en tot dertig dagen via de Stripe CLI, gecontroleerd op 30 september 2026. Die retry-, duplicate- en volgorde-eigenschappen zijn onderdeel van het webhookcontract. Behandel ze dus als normale testgevallen, niet als exotische pech.

Bij Shopify geldt hetzelfde patroon: de platformdocumentatie zegt dat levering binnen één onderwerp of over onderwerpen heen niet gegarandeerd in volgorde staat. Gebruik de X-Shopify-Webhook-Id voor dubbele bezorging en X-Shopify-Triggered-At of updated_at om gebeurtenissen te ordenen. Die identifiers en volgorderegels staan in de actuele webhookdocumentatie, gecontroleerd op 30 september 2026.

3. Zet de ledger vóór de eerste side effect

De belangrijkste ontwerpkeuze is de volgorde: eerst registreren, daarna handelen. Bij ontvangst maak je een ledgerregel met processing. Bestaat dezelfde unieke sleutel al met succeeded, dan wordt de poging een no-op. Bestaat hij met processing, dan behandel je hem als mogelijke gelijktijdige retry. Bestaat hij met failed, dan mag alleen het afgesproken replaypad hem opnieuw aanbieden.

Gebruik voor de unieke sleutel bijvoorbeeld shopify:evt_1042_paid:moneybird_invoice. Leg ook source_key vast, want twee verschillende events kunnen naar hetzelfde bedrijfsobject wijzen. Als je alleen op event-ID dedupliceert, kan een tweede event voor hetzelfde order alsnog een tweede factuur maken.

Een idempotente handeling geeft bij één of tien identieke pogingen hetzelfde zakelijke resultaat. De ledger is je eigen langetermijnbewijs. Gebruik de Stripe-sleutel dus niet als enige vangnet: Stripe kan idempotentiesleutels automatisch verwijderen zodra ze minstens 24 uur oud zijn en behandelt hergebruik daarna als een nieuwe aanvraag. Stripe vergelijkt bij hergebruik ook de parameters. De actuele Stripe-regels voor sleutellengte, parametervergelijking en de bewaartermijn staan hier, gecontroleerd op 30 september 2026.

Een onafhankelijke productie-uitwerking van hetzelfde probleem gebruikt daarom een unieke event-ID, schrijft het event vóór de bedrijfslogica weg, markeert processed_at pas na succes en houdt fouten op diezelfde rij bij. Insert-first en process-second maken replay zichtbaar zonder een tweede side effect, bijgewerkt op 1 augustus 2026 en gecontroleerd op 30 september 2026. In een no-code tool hoeft de tabel niet mooi te zijn. Zij moet wel vóór de factuur, betaling, voorraadmutatie of mail bestaan.

4. Scheid tijdelijke fouten van zakelijke fouten

Een timeout, een 429 rate limit en een tijdelijke 5xx-fout mogen opnieuw proberen. Een ontbrekend verplicht veld, een verlopen machtiging of een conflict met een bestaande order moet naar een andere route. Als je alle fouten retryt, maak je van een dataprobleem een wachtrij vol identieke pogingen.

In n8n zet je bij nodes die een externe API aanroepen Retry On Fail aan en geef je een wachttijd tussen pogingen. Voor grotere batches combineer je Loop Over Items met Wait, zodat je niet in één keer door een rate limit heen schiet. n8n beschrijft beide routes en de instelling Wait Between Tries, bijgewerkt op 21 augustus 2026 en gecontroleerd op 30 september 2026. Laat een kritieke fout daarna de flow stoppen met Stop And Error en stuur hem via een Error Workflow met Error Trigger naar je queue of alerting. De actuele n8n-documentatie laat zien dat de Error Trigger onder meer execution-ID, foutmelding en laatste node kan ontvangen. Daarmee kun je een exception op een echte uitvoering terugvinden, gecontroleerd op 30 september 2026.

Gebruik je de Wait-node voor een menselijke beslissing of een begrensde pauze, leg dan de hervatroute en de deadline vast. n8n kan hervatten na een tijdsinterval, een webhookaanroep of een formulier; met Limit Wait Time voorkom je een flow die eeuwig blijft hangen. De actuele Wait-documentatie beschrijft de resume-URL, authenticatie en tijdslimiet, gecontroleerd op 30 september 2026.

In Make voeg je op de falende module een Retry error handler toe. Make bewaart bij die route de fout, de gegevens en de resterende flow als incomplete execution. Automatisch opnieuw proberen kan bijvoorbeeld drie keer met vijftien minuten ertussen; zonder automatische afronding blijft het geval in Incomplete Executions staan. Zet Store incomplete executions bewust aan. De actuele Make-uitleg beschrijft ook het verschil tussen Retry, Resume, Commit en Rollback, gecontroleerd op 30 september 2026.

Test ook de negatieve kant: een 400-fout op een ongeldig btw-nummer mag niet drie keer dezelfde API-call doen. Markeer hem als needs_human, zet de oorspronkelijke payload in de queue en laat de eigenaar bepalen of het veld wordt aangevuld of het record wordt afgewezen.

5. Bewijs duplicate, replay en out-of-order apart

Een geslaagde eerste run bewijst bijna niets over herhaalveiligheid. Voer daarom drie aparte proeven uit en vergelijk na elke proef de ledger, de doeldata en de neveneffecten.

Bij duplicate stuur je dezelfde event_id twee keer vrijwel gelijktijdig. Verwacht: één ledgerrecord, één target_id, één factuur of mutatie, en één logregel die de tweede ontvangst als duplicate markeert. Een check-then-insert zonder unieke constraint kan onder gelijktijdige druk alsnog dubbel gaan. Een onafhankelijke praktijknotitie laat precies die race zien en kiest daarom voor extra beveiliging op de verwerkingsstappen én op de eerste webhookhandler. De duplicate-check moet ook bij parallelle uitvoering een harde opslaggrens hebben, gepubliceerd op 9 juni 2024 en gecontroleerd op 30 september 2026.

Bij replay laat je dezelfde payload opnieuw lopen nadat de eerste run succeeded is. Verwacht: geen nieuwe side effect, wel een traceerbare replay met reden en tijdstip. Replay de payload ook nadat je na een timeout niet weet of de doelactie is aangekomen. Dan moet de ledger of de doelreferentie beslissen, niet een nieuwe willekeurige idempotentiesleutel.

Bij out-of-order verwerk je eerst de nieuwere versie. Je handler vergelijkt expected_version met de laatst verwerkte versie, of haalt de actuele toestand uit de bron op voordat hij schrijft. Gebruik nooit de ontvangsttijd als waarheid. Een gebeurtenis is een signaal dat iets veranderde, niet automatisch de laatste toestand. Voor betalingen kan invoice.paid bijvoorbeeld vóór een eerder aangemaakt object binnenkomen; Stripe adviseert in dat geval het ontbrekende object via de API op te halen.

Hetzelfde principe staat centraal in een eigen ledger: received_at vertelt wanneer je iets zag, source_updated_at of een bronversie vertelt wat nieuwer is. Bewaar beide. Zo kun je verklaren waarom event 11 later binnenkwam dan event 12 zonder dat je de actuele order terugschrijft naar een oude toestand.

6. Maak van uitzonderingen werk met eigenaar en SLA

Een uitzonderingsqueue is geen vuilnisbak voor fouten. Geef elke categorie een eigenaar, deadline en toegestane beslissing. Voorbeeld:

Zet de beslissing zelf ook in de queue: resolved, replayed, rejected of manual_action. Bij documentstromen zie je dezelfde vorm terug in UBL-facturen met bronmatch, uitzonderingsqueue en menselijke vrijgave. Bewaar wie besliste, wanneer, op basis van welk bewijs en welke doel-ID ontstond. De mens moet de side effect kunnen zien vóór hij hem vrijgeeft. Dat sluit aan op het verschil tussen een menselijke goedkeuringspoort en achteraf monitoren: een actiegerichte goedkeuringspoort laat de flow wachten vóór een risicovolle handeling en is dus iets anders dan een alert na afloop.

Maak de SLA concreet genoeg om te escaleren. “Zo snel mogelijk” is geen deadline. Als de eigenaar na vier werkuren niet heeft beslist, gaat het item naar een tweede eigenaar en blijft de downstream-actie geblokkeerd. Voor een betaling of verzending mag de veilige standaard nooit zijn: toch maar uitvoeren.

7. Voer de vrijgaveproef twee keer uit

Draai de volledige fixture-set eerst vanaf een lege testomgeving. Daarna reset je alleen de fixtures die dat veilig toelaten en bied je dezelfde gebeurtenissen opnieuw aan in een andere volgorde. Neem ook een batch op waarin de duplicate en timeout gelijktijdig lopen. Zo test je de flow die je echt gaat beheren, niet het scherm waarop je hem hebt gebouwd.

Leg per fixture vast:

• de beginstand en de verwachte eindstand;
• het aantal toegestane doelmutaties;
• het aantal ledgerregels en hun status;
• de exceptionstatus, eigenaar en deadline;
• de rollbackactie en de tijd waarin die is uitgevoerd;
• de link naar de uitvoering, payload en eventuele handmatige beslissing.

Stel vervolgens één KPI vast: de veilige proefbatchscore. De teller is het aantal fixtures met de juiste eindstand, exact de toegestane side effects, een complete ledgerregel en een correcte uitzonderingsbeslissing. De noemer is het totale aantal fixtures. De vrijgavegrens is 100 procent. Eén dubbele factuur, één stale overwrite, één verdwenen event of één exception zonder eigenaar maakt de score ongeldig en activeert de stopregel.

Die ene score vervangt geen monitoring na livegang. Hij beantwoordt wel de vrijgavevraag zonder discussie: de vooraf afgesproken proeven zijn allemaal goed, of productie wacht.

Valkuilen die je vrijgave ongeldig maken

• Je test alleen de happy path. Een nette eerste run toont niet wat er gebeurt als de API na schrijven een timeout geeft. Voeg een timeout ná verzending toe, zodat je de onbekende status test.
• Je maakt bij elke retry een nieuwe sleutel. Dan is de retry voor je doel-API een nieuwe opdracht. Bereken de sleutel vóór de eerste poging en hergebruik hem bij retry en replay.
• Je retryt ook zakelijke fouten. Een 400 door een ongeldig veld wordt niet beter door wachten. Routeer syntaxis, machtiging en mappingfouten naar de queue.
• Je gebruikt alleen event-ID als bedrijfs-ID. Eén order kan meerdere geldige gebeurtenissen hebben. Combineer event-id voor bezorging met order-id voor het zakelijke object en leg de relatie vast.
• Je vertrouwt op ontvangstvolgorde. Parallelle systemen leveren geen betrouwbare volgorde. Gebruik bronversie of haal de actuele bronstatus opnieuw op.
• Je laat Continue On Error kritieke stappen overslaan. Een Slack-melding mag soms apart falen. Een factuur, voorraadmutatie of betaling mag niet stilzwijgend worden overgeslagen.
• Je behandelt deduplicatie als idempotentie. Een tijdelijke dedupefunctie kan dubbele belasting verminderen, maar is geen bewijs dat een side effect nooit dubbel ontstaat. Houd je ledger en unieke constraint.
• Je keurt een totaal goed zonder sleutelset. Twee gelijke aantallen kunnen één ontbrekend en één dubbel record verbergen. Vergelijk sleutels, status en totalen.
• Je maakt de menselijke queue te laat. Als je pas na de eerste fout bedenkt wie beslist, blijft de flow hangen. Maak eigenaar en deadline onderdeel van de fixture.
• Je gebruikt productiecredentials in een proef. Een fixture die echt een factuur mailt is geen test maar een incident. Scheid credentials, endpoints en notificatiekanalen.
• Je bewaart geen bewijs. Een screenshot van een groene run is niet genoeg. Bewaar payload, uitvoering, ledgerregel, doel-ID en vrijgavebesluit.
• Je vertrouwt op de retryknop als herstelplan. In n8n is opnieuw uitvoeren een nieuwe uitvoering, geen magisch checkpoint. Herstelbaarheid komt uit je eigen sleutels, status en batchgrenzen.

Beslis-kader: wanneer is kant-en-klaar genoeg?

De juiste route hangt af van de foutkosten en de hoeveelheid controle die je nodig hebt. Kant-en-klaar is prima als het proces simpel, omkeerbaar en handmatig controleerbaar is. No-code met ledger en uitzonderingsqueue past bij standaard-API’s met een technische eigenaar. Maatwerk verdient zijn plek zodra meerdere systemen elk een deel van de waarheid bezitten, een side effect niet terug te draaien is of je een eigen herstel- en auditlaag nodig hebt.

Gebruik deze drie beslisregels:

• Kant-en-klaar: checklist en handmatige vrijgave. Kies dit voor interne meldingen, concepten en eenvoudige synchronisatie zonder geld, voorraad of klantbelofte. Je test nog steeds de zeven fixtures, maar een mens mag de laatste actie handmatig uitvoeren.
• No-code: fixture-set, ledger en uitzonderingsqueue. Kies n8n of Make voor standaard-API’s, beperkte datamodellen en een eigenaar die wekelijks de queue en maandelijkse fixturetest beheert. Dit is vaak de beste route voor een MKB-proces dat belangrijk is, maar nog geen aparte integratieservice nodig heeft.
• Maatwerk: aparte replay- en reconciliatieservice. Kies dit bij betalingen, voorraad, meerdere bronhouders, hoge volumes, strakke hersteltijden of een vereiste audittrail per veld. Een no-code canvas kan dan nog steeds de orkestratie tonen, maar de ledger, unieke constraints en reconciliatie horen in een laag die je zelf kunt testen en beheren.

Kies niet op het aantal nodes. Een flow met vier nodes die een factuur aanmaakt kan risicovoller zijn dan een flow met veertig nodes die alleen een intern rapport opbouwt. Vraag per stap: kan ik het effect terugdraaien, bestaat er een unieke sleutel, wie bezit de bronwaarde en wie beslist bij twijfel?

Twijfel je tussen no-code en maatwerk, voer dan eerst de fixtureproef uit. Als je geen unieke sleutel kunt vastleggen, geen veilige testomgeving kunt maken of niet kunt aanwijzen wie een exception oplost, is de workflow nog niet klaar voor productie, ongeacht de tool.

Uitgewerkt voorbeeld: Shopify, Stripe, n8n en Moneybird

Dit is een fictief oefenscenario voor een webshop die een betaalde Shopify-order via Stripe naar n8n en daarna naar Moneybird brengt. n8n maakt een conceptfactuur en stuurt pas na een controle een interne Slack-melding. Een echte factuurmail valt buiten de test. De testpolicy is vooraf: maximaal drie retries voor tijdelijke fouten, geen retry op 4xx-validatiefouten, vier werkuren SLA voor Finance-uitzonderingen en rollback binnen vijftien minuten na een kritieke fout. Die waarden zijn startwaarden voor dit voorbeeld, geen universele norm.

De ledger gebruikt source_key, event_id, operation_key, source_version, status, target_id, attempts, owner en deadline. operation_key is bijvoorbeeld shopify:ORD-1042:moneybird-draft. De testdata bevat een order van 249 euro met btw, een geldig Stripe PaymentIntent-ID en een Shopify-versie 12.

Bij FX-TO-02 kwam de timeout nadat Moneybird de aanvraag mogelijk had verwerkt, maar vóór n8n het antwoord zag. De flow vroeg daarom eerst via de operation key of er al een concept bestond. Pas als de lookup niets vond, mocht een nieuwe create-call worden gedaan. Dit is het moment waarop een gewone retry vaak een dubbele factuur maakt.

Bij FX-OOO-04 accepteerde de flow niet simpelweg wat als laatste binnenkwam. Hij vergeleek de bronversie en haalde de actuele Shopify-order op voordat hij het doel bijwerkte. Bij een Stripe-event zou dezelfde regel gelden: gebruik het event als aanleiding, maar haal de actuele betaalstatus op wanneer de volgorde niet betrouwbaar is.

De tweede run bood FX-DUP-03, FX-RP-05 en FX-OOO-04 in een andere volgorde aan. De zeven fixtures hadden allemaal de juiste eindstand, de side-effectteller bleef exact op de afgesproken aantallen en alle queue-items hadden een eigenaar. De veilige proefbatchscore was daarom 7 van 7, oftewel 100 procent. Pas toen ging de productiepoort open.

De vrijgavekaart bevatte vier namen: een technische eigenaar voor n8n en credentials, een proceseigenaar voor orders, Finance voor btw-uitzonderingen en één operationeel verantwoordelijke met go/no-go-mandaat. De rollback bestond uit de productieworkflow uitschakelen, de vorige versie activeren, de open queue behouden en de nieuwe events niet weggooien. Een rollback die de ledger wist, maakt het herstel juist onveilig. Leg ook je eigen hersteltijd vast; RTO, RPO, fallback en reconciliatie horen bij dezelfde vrijgavebeslissing.

Vergelijkingstabel: vier manieren om te accepteren

Onderstaande prijzen en productdetails zijn gecontroleerd op 30 september 2026. Websiteprijzen kunnen per land, belasting en betaaltermijn verschillen. De tabel vergelijkt de test- en beheerlast, met licentie als één onderdeel.

Voor een interne melding is de native route vaak verstandig. Voor een standaard order- of factuurstroom is Make of n8n bruikbaar zolang je de ledger en uitzonderingsqueue buiten de happy path serieus bouwt. Voor betalingen, voorraad en meerdere systemen is een eigen controlelaag meestal de kortste weg naar bewijs. De toolnaam verandert, maar de vrijgave-eis blijft dezelfde.

Een workflow is productierijp wanneer je niet meer hoeft te geloven dat hij goed gaat. Je hebt dan gezien wat er gebeurt als de API zwijgt, hetzelfde event terugkomt, de volgorde breekt en een mens moet beslissen. De laatste groene run is niet het bewijs. Het bewijs is dat je de fout opnieuw kunt uitvoeren, de side effect op één kunt houden en precies kunt aanwijzen wie de resterende uitzondering oplost.