SaaS-uitval herstellen: van RTO en RPO tot reconciliatie en vrijgave

Je hebt net een SaaS-storing gemeld. De provider zet de status op groen, maar in Shopify ontbreken drie orders, Stripe heeft een betaling opnieuw aangeboden en je fulfilmentflow staat nog stil. Dat is het moment waarop veel teams te vroeg hervatten.

Een provider is hersteld wanneer zijn dienst bereikbaar is. Jij bent hersteld wanneer je kunt aantonen welke mutaties tijdens de storing ontstonden, welke dubbel binnenkwamen, welke bron leidend is en wie de resterende uitzonderingen heeft vrijgegeven. Deze gids bouwt die keten op voor ondernemers en teams die afhankelijk zijn van SaaS voor orders, betalingen, klantdata, planning of facturatie.

Een SaaS-herstelrunbook is een getest werkdocument dat beschrijft wat je doet bij uitval van een leverancier: wanneer je overschakelt op een fallback, welke gegevens je tijdens de storing vastlegt, hoe je na herstel gemiste mutaties terughaalt, hoe je verschillen reconcilieert en wie de bedrijfsvoering weer vrijgeeft. Het koppelt technische controles aan een besluit van een mens met mandaat.

Wat heb je nodig voordat je begint?

Een herstelrunbook maakt SaaS-uitval uitvoerbaar door per kritieke datastroom het doel, de bron, de fallback, de herstelgrens en de vrijgave vast te leggen. Verzamel eerst de namen, toegangen, sleutels en testdata. Zonder die basis wordt een storing een improvisatie met echte orders en betalingen.

Leg deze onderdelen klaar:

• Een bronnenkaart. Noteer per proces de SaaS-provider, applicatie, eigenaar, vervanger, API, exportmogelijkheid, statuspagina en tweede contactroute. Een kaart van alleen applicatienamen is te grof. Zet er ook de concrete stroom bij, zoals Shopify-orders naar n8n, Stripe-betalingen naar Moneybird of klantupdates naar een CRM.
• RTO en RPO per proces. RTO is de maximale tijd waarbinnen je een proces weer wilt laten draaien. RPO is het punt in de tijd tot waar je data na een storing moet kunnen terugbrengen, zoals NIST het definieert. Kies ze per stroom, niet per leverancier. Een rapportage kan vier uur wachten; een betaalstatus misschien vijftien minuten.
• Een offline fallback. Gebruik een eigen formulier of versleutelde intake met een oplopend volgnummer, bijvoorbeeld FB-20260920-0001. Sla tijdstip in UTC, klant- of orderreferentie, bedrag, gewenste actie en status op. Zet geen nieuwe betaling of verzending automatisch door zolang de bronapplicatie niet kan bevestigen dat de mutatie uniek is. Een Google Sheet kan voor een kleine noodset als tijdelijke invoer dienen, maar maak hem nooit je blijvende administratie.
• Rollen met mandaat. Wijs een incidentleider aan, een technische eigenaar per flow, iemand die de fallback beheert en een zakelijke vrijgever voor geld, voorraad of klantcommunicatie. De incidentleider mag een schrijver stoppen. De vrijgever mag een conflict afwijzen. Dat zijn twee verschillende taken.
• Een herstelopslag. Bewaar exports, event-ID’s, logs, hashes of checksums, cursors en beslissingen in een omgeving waar de SaaS-provider niet zelfstandig bij kan. Denk aan versleutelde objectopslag met beperkte schrijfrechten en versiebeheer. Test ook het teruglezen. Een export die nooit is geopend, is een aanname.
• Een foutqueue. Per mislukte of onduidelijke mutatie bewaar je bron, event-ID, zakelijke sleutel, ontvangen tijd, foutmelding, aantal pogingen, volgende actie, eigenaar en status. Gebruik statussen als nieuw, opnieuw proberen, handmatige controle, vrijgegeven en afgewezen.
• Een proefset. Maak twintig tot vijftig records met een normale order, een annulering, een retour, een dubbele aanbieding, een ontbrekende relatie, een gedeeltelijke levering en een bedrag met afronding. Gebruik een testadministratie in Moneybird of Exact Online waar dat kan.
• Een communicatieroute. Een eigen statuspagina of een vooraf ingericht incidentkanaal voorkomt dat support, klanten en leveranciers verschillende verhalen krijgen. Atlassian Statuspage heeft op 20 september 2026 een gratis plan met 100 abonnees, 25 componenten, twee teamleden, e-mail-, Slack- en Microsoft Teams-meldingen en een REST API. Dat is genoeg voor een kleine organisatie om de basisroute te oefenen, niet genoeg om je herstelproces te vervangen.

De indeling sluit aan op de bredere single source of truth per veld: elk veld heeft een bronhouder, een stabiele sleutel, een synchronisatieregel en een herstelpad. Dat betekent niet dat één database alles bezit. Shopify kan een order aanmaken, Stripe de betaling bevestigen en Moneybird de boeking bewaren.

Concrete stappen: van storing naar gecontroleerde vrijgave

Volg de stappen in deze volgorde. Elke stap heeft een controlepunt. Sla geen controle over omdat de provider zegt dat de storing is opgelost.

1. Zet RTO en RPO om in een besluit

Schrijf per stroom één regel met vier waarden: maximaal offline, maximaal dataverlies, wie beslist en wat je tijdens de fallback mag doen. Maak de grens meetbaar.

Een bruikbare start voor een webshop kan zijn:

Dit zijn voorbeeldwaarden, geen norm. Bespreek per rij wat een uur stilstand, een gemiste order of een te vroege verzending werkelijk kost. NIST SP 800-34 Rev. 1, gepubliceerd in mei 2010 en nog steeds een bruikbaar planningsreferentiepunt, behandelt contingency planning als een proces waarin je systemen, prioriteiten, afhankelijkheden en herstelprocedures vastlegt.

Controlepunt: iemand uit de operatie kan zeggen wanneer de fallback start, en iemand uit finance kan zeggen wanneer een betaling nog niet mag worden vrijgegeven.

2. Bevries de juiste schrijfactie en markeer het incidentvenster

Noteer het moment van de eerste fout, de laatste geslaagde run en de laatste bevestigde bronstand. Maak daar een venster van, bijvoorbeeld 09:47:00 UTC tot 10:32:00 UTC. Neem een overlap mee aan beide kanten. Een exacte tijdgrens laat records vallen wanneer klokken of queues niet gelijk lopen.

Pauzeer de flow die nieuwe effecten maakt. Laat een read-only dashboard, een intake of een queue wel doorlopen als die onafhankelijk werkt. Zet de actie zichtbaar op incident hold, niet alleen uit in een persoonlijke browser. Maak in dezelfde stap een incident-ID aan en koppel daar logs, leveranciersticket, screenshots en besluiten aan.

Controlepunt: je kunt later uitleggen welke mutaties vóór, tijdens en na de storing vielen, zonder op herinneringen van één medewerker te vertrouwen.

3. Schakel over op een fallback die geen tweede waarheid wordt

Start de noodintake met een uniek volgnummer. Leg per binnengekomen mutatie vast of het om een nieuwe order, wijziging, annulering, refund of informatievraag gaat. Neem een bestaande klant- of orderreferentie over als die bekend is. Maak geen tweede order-ID die later stil opgaat in de eerste. Gebruik een koppeltabel tussen fallback-ID en bron-ID.

Bij een betaling registreer je onbevestigd in plaats van betaald. Bij voorraad noteer je de laatste bevestigde stand en de handmatige reservering apart. Bij een annulering zet je de actie in een wachtrij met reden. De fallback mag de klant helpen, maar mag geen onomkeerbare stap verbergen.

Houd de noodlijst klein. Verzamel alleen wat je nodig hebt om later veilig terug te schrijven. Een vrije tekstkolom met complete betaalgegevens of klantnotities maakt het herstel een privacy-incident.

Controlepunt: elke fallback-regel heeft precies één status, één eigenaar en één sleutel waarmee je hem later aan de bron kunt koppelen.

4. Communiceer met een vast ritme

Meld intern wat er niet werkt, welke acties zijn gepauzeerd, wat de volgende update oplevert en wie mag vrijgeven. Geef klanten alleen een belofte die je kunt testen. “Nieuwe bestellingen worden verwerkt zodra betaling en voorraad zijn gecontroleerd” is beter dan “alles is bijna opgelost”.

Een publieke statuspagina helpt bij de communicatie, niet bij de technische waarheid. Statuspage positioneert zich als communicatieonderdeel van incidentmanagement en ondersteunt componenten voor afhankelijkheden zoals Stripe en Shopify. Gebruik die componenten om de impact te beschrijven, maar koppel de herstelbeslissing aan je eigen reconciliatiekaart.

Plan updates op vaste momenten, bijvoorbeeld elke dertig minuten tijdens de storing en direct bij een verandering van fase. Noteer ook een intern tijdstip voor de volgende actie. Een incident zonder eigenaar voor de volgende update blijft hangen, ook als engineers hard werken.

Controlepunt: support kan dezelfde status zien als de incidentleider en weet welke vragen naar de fallback-eigenaar gaan.

5. Herstel de bron, exporteer het venster en haal events gecontroleerd in

Wanneer de SaaS weer bereikbaar is, maak je eerst een bronexport van het incidentvenster en de overlap. Bewaar de originele payload of export naast een checksum en een tijdstip. Verwerk daarna de achterstand met dezelfde validatie en idempotentiesleutel als de normale route. Maak geen aparte snelle herstelcode die andere regels gebruikt.

Voor Stripe is er een concrete herstelhaak. Stripe kan undelivered events automatisch tot drie dagen opnieuw aanbieden. De List Events API kan events uit de laatste dertig dagen teruggeven met delivery_success=false; markeer in je eigen database eerst processing en daarna processed, zodat een handmatige backfill en automatische retries elkaar niet dubbel uitvoeren, zoals de Stripe-herstelprocedure voor undelivered events voorschrijft.

Voor Shopify moet je uitgaan van minstens één aflevering. Shopify controleert de HMAC op de ruwe payload en levert een delivery-ID waarmee je duplicaten herkent. De Shopify-documentatie voor webhookleveringen adviseert idempotente verwerking en onderscheidt de delivery-ID van de event-ID. Mislukte afleveringen worden volgens de actuele Shopify-herstelhandleiding tot acht keer in vier uur opnieuw geprobeerd; daarna kan het abonnement worden verwijderd. Plan daarom naast retries altijd een bronbackfill.

Een updated_at-filter is geen bewijs van volledigheid. Neem verwijderingen, retouren, statuswissels en records zonder nieuwe tijdstempel mee. Gebruik een cursor plus overlap en schrijf per record een herstelresultaat. Bij een externe API moet je ook je live verkeer beschermen. Doseer de backfill en reserveer capaciteit voor nieuwe events.

Voor nieuwe schrijfopdrachten gebruik je een idempotentiesleutel. Een herhaalde Stripe-aanvraag met dezelfde sleutel krijgt volgens de Stripe-uitleg over idempotente aanvragen hetzelfde resultaat zolang endpoint en parameters bij elkaar blijven.

Controlepunt: dezelfde event-ID of zakelijke sleutel twee keer aanbieden heeft één bedrijfs-effect en een zichtbare logregel.

6. Reconcileer op telling, sleutelset, velden en bedrijfstotaal

Vergelijk niet alleen de groene workflowstatus. Maak per stroom vier controles:

1. Telling: hoeveel bronrecords, doelrecords, fallback-regels en queue-items zijn er?
2. Sleutelset: welke sleutels staan alleen in de bron, alleen in het doel, of aan beide kanten?
3. Veldwaarde: verschillen status, bedrag, valuta, belasting, voorraadstand of timestamp?
4. Bedrijfstotaal: kloppen som van betalingen, aantal orders, openstaande facturen en beschikbare voorraad per locatie?

Gebruik vier uitkomsten voor de sleutelvergelijking: alleen bron, alleen doel, beide gelijk en beide verschillend. Koppel bij elk verschil een oorzaakcategorie, bijvoorbeeld gemiste event, dubbele aflevering, late wijziging, handmatige correctie, verwijdering of onbekende sleutel.

Webhooks zijn snel, maar ze bewijzen niet dat je dataset compleet is. Een onafhankelijke praktijkuitleg over Shopify-webhooks en reconciliatie, bijgewerkt op 10 september 2026, maakt precies dat onderscheid: events houden data vers, een periodieke vergelijking controleert volledigheid en afwijkingen. Gebruik daarom webhooks voor snelheid en reconciliatie voor waarheid.

Een verschil is geen uitnodiging om de laatste schrijver te laten winnen. Een refund kan later zijn dan de order. Een handmatige voorraadcorrectie kan bewust afwijken. Laat de bronhouder per veld beslissen en bewaar oude waarde, nieuwe waarde, reden, uitvoerder en tijdstip.

Controlepunt: je hebt een lijst met nul onverklaarde verschillen, of een lijst waarin elk resterend verschil een besluit, eigenaar en uiterste datum heeft.

7. Laat een mens risicovolle effecten vrijgeven

Maak een vrijgavekaart met één regel per openstaand verschil. Toon de bronwaarde, doelwaarde, sleutel, event-ID, bedrag of voorraadimpact, voorgestelde actie, bewijslink, naam van de behandelaar en naam van de vrijgever. De vrijgever mag de bronwaarde niet stil overschrijven. Een correctie is een afzonderlijke actie met reden.

Gebruik deze uitkomsten:

• Automatisch verwerkt: event uniek, validatie geslaagd, sleutel bekend en bedrijfstotaal gelijk.
• Handmatig vrijgeven: één kandidaat, bewijs compleet, effect beperkt en regel vooraf goedgekeurd.
• Blokkeren: geld, voorraad, klantbelofte of verwijdering is geraakt en de oorzaak is niet bewezen.
• Afwijzen en opnieuw uitzoeken: bronrecord ongeldig, sleutel dubbel of payload beschadigd.

Functiescheiding is praktisch: de persoon die de fallback invoert, keurt zijn eigen refund niet goed. Bij een klein team kan één persoon tijdelijk twee rollen hebben, maar noteer die afwijking en laat een tweede persoon achteraf controleren.

Controlepunt: iedere automatische correctie is reproduceerbaar en iedere handmatige correctie heeft een naam, reden en tijdstip.

8. Hervat gefaseerd en sluit pas met bewijs

Verwerk eerst een kleine batch, bijvoorbeeld tien orders of één uur aan mutaties. Controleer de vier reconciliatiecontroles opnieuw. Open daarna de live schrijfstroom voor nieuwe records, terwijl de achterstand in een begrensde queue doorloopt. Houd de fallback open tot de laatste queue-regel een besluit heeft.

Meet na hervatting de foutgraad, latency, queue-omvang, dubbele aanbiedingen en verschillen per uur. Kijk ook naar late events. Een eerste geslaagde run kan een tweede statuswijziging missen. Laat de zakelijke vrijgever de herstelkaart tekenen met incident-ID, venster, totalen, open uitzonderingen, rest-risico en tijdstip.

Controlepunt: iemand die niet bij het incident zat, kan uit de kaart reconstrueren wat er is gebeurd en waarom de operatie weer open mocht.

Waar loopt een SaaS-herstelrunbook in de praktijk vast?

De meeste problemen ontstaan niet bij het openen van de providerapplicatie. Ze ontstaan bij de grens tussen twee systemen, een stille retry of een menselijke beslissing die nergens is vastgelegd. Gebruik deze faalmodi als testgevallen voor je eerste oefening.

• Je verwart provider-SLA met jouw RTO. Een leverancier kan een beschikbaarheidsdoel hebben dat niets zegt over het herstellen van jouw queue, exports of boekingen. Schrijf je eigen klok uit en test hem met een stopwatch.
• De fallback wordt een tweede administratie. Een noodlijst zonder uniek nummer en koppeltabel raakt los van de bron. Gebruik een fallback-ID, bronreferentie, status en eigenaar.
• Je replayt vanaf het exacte storingstijdstip. Een event rond de grens valt uit, of komt dubbel binnen. Gebruik een overlapvenster en idempotente upsert.
• Je vertrouwt op updated_at zonder te controleren hoe de bron klokt. Tijdzones, late wijzigingen en verwijderingen verschuiven de dataset. Backfill op cursor, sleutelset en expliciete verwijderstatus.
• De provider is terug, maar de eventabonnementen zijn dat niet. Shopify kan na acht mislukte afleveringen in vier uur een abonnement verwijderen. Controleer subscriptions, delivery logs en de bronset voordat je hervat.
• De backfill verdringt live verkeer. Een grote export kan API-limieten of workers opslokken. Doseer herstel, reserveer capaciteit en maak de voortgang zichtbaar.
• Een groene flow verbergt een fout. 200 OK betekent ontvangst, niet dat de downstream-boeking is gelukt. Bewaar ontvangst, verwerking en vrijgave als aparte statussen.
• Een mens keurt een totaal goed zonder records te bekijken. Gelijke bedragen kunnen een dubbele order en een ontbrekende order tegelijk maskeren. Controleer sleutelset en uitzonderingen naast het totaal.
• De fallback bewaart te veel persoonsgegevens. Een noodsheet met complete betaal- of klantnotities blijft vaak langer staan dan de storing. Leg alleen de minimale herstelvelden vast, beperk toegang en plan verwijdering.
• Niemand test de oefening. Een runbook dat nooit een echte export heeft teruggelezen, is documentatie. Plan een tabletop, een technische replay en een volledige herstelproef met bewijs.

Welk herstelpad past bij jouw situatie?

Kies niet op de naam van de automatiseringstool. Kies op foutkosten, aantal systemen, gewenste RPO, uitzonderingen en de mensen die het later moeten beheren. Een single source of truth is in deze context een governance-uitkomst met afgesproken definities, bronnen en reconciliatie, geen dashboard en geen verplichte centrale database, zoals de financiële praktijkuitleg over SSOT helder maakt.

Gebruik deze praktische beslisregels:

• Kant-en-klaar: handmatige fallback met native export. Kies dit bij één kritieke SaaS, weinig mutaties tijdens uitval, een ruime RTO en een team dat de herstelkaart handmatig kan controleren. De licentiekosten blijven laag; de zwakke plek is menselijke capaciteit.
• No-code: replay en reconciliatie in Make. Kies dit voor één of twee standaard-API’s, een technische eigenaar en weinig uitzonderingslogica. De actuele Make-prijspagina toont een gratis plan met 1.000 credits per maand, Core voor 10.000 credits vanaf 9 dollar per maand, Pro vanaf 16 dollar en Teams vanaf 29 dollar, gecontroleerd op 20 september 2026. Een credit is een moduleactie. Reken dus je herstelpad door, niet alleen het aantal scenario’s.
• Self-hosted: herstelworkflow in n8n. Kies dit als je eigen infrastructuur, secrets en queue wilt beheren en je technische eigenaar retries, updates en back-ups kan dragen. n8n vermeldt op 20 september 2026 een gratis Community Edition voor self-hosting. n8n Cloud Starter kost 20 euro per maand bij jaarlijkse betaling voor 2.500 workflowexecuties; Pro kost 50 euro voor 10.000. De prijs is per volledige workflowuitvoering, maar hosting, logging en beheer van self-hosted zijn jouw rekening.
• Maatwerk: idempotente herstelservice met reconciliatie en vrijgave. Kies dit zodra meerdere systemen verschillende velden bezitten, events geld of voorraad bewegen, je onder een uur RPO wilt blijven of je bewijs per herstelrun nodig hebt. Je bouwt dan een eigen herstelcursor, foutqueue, koppeltabel, vrijgavekaart en auditlog. Dat kost meer tijd vooraf, maar een half-passende connector kost je bij elke storing opnieuw beslissingen.

Deze drempels zijn praktische startpunten, geen garanties. Als je twijfelt, tel dan eerst de uitzonderingen in één recente maand. Meer dan één bronhouder, één onomkeerbaar effect en één handmatige correctie zijn vaak al genoeg om de controlelaag zwaarder te maken dan de koppeling zelf.

Uitgewerkt voorbeeld: Shopify en Stripe na 45 minuten uitval

Stel: een Nederlandse webshop verwerkt gemiddeld 48 orders per uur. De stack bestaat uit Shopify voor ordercreatie, Stripe voor betalingen, n8n voor de workflow en Moneybird voor facturatie. Dit is een fictief oefenscenario, bedoeld om de beslislogica zichtbaar te maken.

De eigenaar heeft vooraf een RTO van twee uur voor orders en een RPO van vijftien minuten gekozen. Een betaling mag nooit automatisch als bevestigd gelden wanneer Stripe niet kan worden geraadpleegd. De fallback gebruikt een eigen formulier met een volgnummer en een aparte status onbevestigd.

10:02 UTC: de storing begint

De Shopify API geeft time-outs en de webhook-endpoint krijgt geen geldige payloads meer. Stripe is bereikbaar. De incidentleider maakt INC-2026-0920-01 aan, markeert de laatste geslaagde Shopify-run om 09:47 UTC en zet de automatische order-naar-Moneybird-flow op incident hold. Support krijgt de instructie om nieuwe aanvragen via het fallbackformulier te registreren.

Tussen 10:02 en 10:47 komen 36 klanten in beeld. Vier willen later betalen, 29 hebben een orderreferentie, drie vragen alleen een wijziging. De 36 regels krijgen fallback-ID’s FB-20260920-0001 tot en met FB-20260920-0036. Geen enkele regel gaat rechtstreeks naar facturatie. De getallen zijn hier bewust gekozen voor het voorbeeld, niet voor een echte webshop.

10:47 UTC: Shopify is weer bereikbaar

De providerstatus is groen. De incidentleider sluit het incident nog niet. Eerst wordt de bronexport opgehaald voor 09:42 tot 10:52 UTC, dus vijf minuten overlap aan beide kanten. De export bevat 35 unieke orders. Eén klant uit de fallback heeft tijdens de storing zelf opnieuw besteld via een ander kanaal; die twee regels krijgen een matchstatus mogelijk dubbel en gaan naar de queue.

Stripe laat in de eventlijst zien welke afleveringen niet succesvol zijn verwerkt. De hersteljob haalt alleen het relevante type op, markeert elke event-ID vóór verwerking als processing en gebruikt daarna dezelfde idempotente handler als live verkeer. Een retry van hetzelfde payment-event wordt een no-op.

11:08 UTC: de eerste reconciliatie

De controlekaart bevat nu:

De twee mogelijke dubbelen worden niet automatisch weggegooid. Eén blijkt een wijziging op een bestaande order, één is een echte tweede bestelling met een ander betaal-ID. De bronhouder van orders en de financiële eigenaar beoordelen beide regels. De eerste wordt aan de bestaande order gekoppeld. De tweede blijft als aparte order staan.

De reconciliatie vergelijkt ook de geldstroom. De orderbedragen en Stripe-betalingen sluiten na de koppeling aan op de factuurvoorstellen in Moneybird. Een ontbrekende refund zou hier als geldverschil blijven staan, ook als het aantal orders gelijk was.

11:32 UTC: vrijgave en nazorg

De vrijgever tekent dat de bron- en doelset gelijk zijn, de dubbele aanbiedingen zijn verklaard, de betaling van iedere vrij te geven order een Stripe-ID heeft en de twee uitzonderingen een reden en auditlog hebben. De eerste batch van tien orders wordt door n8n verwerkt. Na een tweede controle gaat de liveflow open voor nieuwe Shopify-orders. De fallback blijft nog dertig minuten beschikbaar voor late meldingen.

De provider was om 10:47 UTC terug. Het bedrijf was pas om 11:32 UTC terug. Die 45 minuten verschil zijn precies waarom herstel niet eindigt bij “de app doet het weer”. De herstelklok stopt wanneer de bedrijfsuitkomst aantoonbaar klopt en iemand met mandaat het besluit heeft vastgelegd.

Vergelijkingstabel: vier routes naar herstel

Onderstaande bedragen en productdetails zijn gecontroleerd op 20 september 2026. De prijzen zijn websiteprijzen en kunnen per land, valuta, belasting of jaarbetaling verschillen. De inspanningsorde is een praktische inschatting voor één of enkele datastromen, geen offerte.

Voor Make telt iedere moduleactie als credit. Een flow die een event leest, een match zoekt, een record schrijft en een log opslaat verbruikt dus meer dan één credit per mutatie. n8n rekent Cloud volgens zijn huidige prijspagina per volledige workflowuitvoering, terwijl self-hosted geen licentieprijs voor de Community Edition vraagt. “Gratis” betekent daar niet dat server, secrets, back-ups en beheer niets kosten.

Zo test je het runbook voordat je het nodig hebt

Begin met een tabletop van dertig minuten. Laat de incidentleider hardop zeggen wanneer hij schrijfacties stopt, laat de fallback-eigenaar één voorbeeldmutatie invoeren en laat de zakelijke vrijgever één conflict blokkeren. Noteer elke vraag waarop het document geen antwoord geeft.

Doe daarna een technische proef in een testadministratie:

1. Schakel één webhook of API-route bewust uit.
2. Laat vijf normale events, één dubbele, één late wijziging en één verwijdering ontstaan.
3. Controleer of de fallback-ID’s en event-ID’s buiten de SaaS blijven bestaan.
4. Herstel de route en laad het venster met overlap opnieuw in.
5. Vergelijk telling, sleutelset, velden en totalen.
6. Laat een tweede persoon de vrijgavekaart ondertekenen.
7. Meet de echte tijd tot de eerste veilige batch en tot volledige vrijgave.

Test het runbook na een wijziging in API, webhook, authenticatie, betaalprovider of boekhoudpakket opnieuw. De API-uitfasering met register, parallelle route en veilige vrijgave gebruikt dezelfde gedachte: eerst nulmeting en proefset, daarna een route die naast de bestaande kan draaien, pas dan een vrijgave.

Een herstelrunbook is geslaagd wanneer een ander persoon het kan uitvoeren met de beschikbare toegangen en wanneer de uitkomst controleerbaar is. Een groen vinkje is geen herstelbewijs. De echte eindstreep is een verklaarde dataset, een begrensd rest-risico en een menselijke handtekening die later nog te begrijpen is.