Kennisbank

Postmortemanalyse: wat we leren van storingen, crashes en fouten

Bijgewerkt: 18 augustus 2026 · 6 min leestijd

Een postmortemanalyse is een systematisch onderzoek dat wordt uitgevoerd nadat er iets is misgegaan met een technisch systeem: een website die urenlang plat lag, een raket die explodeerde, of een softwareprogramma dat verkeerde beslissingen nam. Het doel is niet om een schuldige aan te wijzen, maar om precies te reconstrueren wat er gebeurde, waarom het gebeurde, en hoe herhaling kan worden voorkomen. De term is geleend uit de geneeskunde: een postmortem of autopsie onderzoekt na de dood wat er in een lichaam is misgegaan. In de techniek doet men hetzelfde met systemen, alleen leeft het "patiënt" meestal nog en moet die straks weer aan het werk.

Een voorbeeld maakt het concreet. Stel dat een webshop een uur lang onbereikbaar is tijdens de drukste verkoopdag van het jaar. Een postmortemanalyse achterhaalt dan: wanneer begon het probleem precies, welk signaal had het eerder kunnen aankondigen, welke technische component faalde als eerste, welke menselijke of organisatorische keuzes daaraan bijdroegen, en welke concrete maatregelen voorkomen dat dit nog eens gebeurt. Het resultaat is meestal een document dat intern — en bij grote techbedrijven steeds vaker ook publiek — wordt gedeeld, zodat anderen ervan kunnen leren.

Wat is het precies?

Een postmortemanalyse volgt doorgaans een vast stramien, ongeacht of het om software, een ruimtevaartmissie of een fabrieksongeval gaat.

Eerst wordt een tijdlijn gereconstrueerd: welke gebeurtenissen vonden wanneer plaats, op basis van logbestanden, meetgegevens, chatberichten of, bij fysieke ongevallen, wrakstukken en sensordata. Deze tijdlijn moet zo feitelijk mogelijk zijn, zonder interpretatie.

Daarna volgt de zoektocht naar de hoofdoorzaak (root cause). Populaire technieken hiervoor zijn de "vijf keer waarom"-methode, waarbij telkens wordt doorgevraagd waarom iets gebeurde totdat de onderliggende oorzaak boven water komt, en het visgraatdiagram (ook wel Ishikawa-diagram), dat mogelijke oorzaken categoriseert naar bijvoorbeeld mens, techniek, proces en omgeving. Belangrijk is dat er zelden één enkele oorzaak is: meestal gaat het om een keten van kleine tekortkomingen die samen een grote storing veroorzaken.

Een cruciaal, en soms lastig, onderdeel is de "blameless" aanpak: de analyse richt zich op systemen en processen, niet op het aanwijzen van individuele schuldigen. De gedachte is dat mensen zelden expres fouten maken; als iemand een verkeerd commando uitvoert, is de echte vraag waarom het systeem dat verkeerde commando toeliet zonder waarschuwing. Deze cultuur, geformuleerd door onder meer techneut John Allspaw bij het Amerikaanse bedrijf Etsy rond 2012, moet voorkomen dat mensen fouten verzwijgen uit angst voor gevolgen — wat toekomstige postmortems juist minder betrouwbaar zou maken.

Tot slot levert een postmortem concrete actiepunten op: technische aanpassingen, extra monitoring, gewijzigde procedures of training. Zonder opvolging blijft een postmortem een papieren exercitie.

Wat wil men ermee bereiken?

Het achterliggende doel is een "lerende organisatie": een team of bedrijf dat fouten niet verstopt, maar er structureel van leert. In de praktijk levert dat verschillende voordelen op.

Ten eerste neemt de betrouwbaarheid van systemen toe, omdat dezelfde fout niet telkens opnieuw optreedt. Ten tweede daalt de gemiddelde hersteltijd bij incidenten, omdat teams door eerdere postmortems sneller herkennen wat er aan de hand is. Ten derde ontstaat er meer vertrouwen, zowel intern tussen collega's als extern bij klanten en gebruikers: een bedrijf dat eerlijk uitlegt wat er misging, oogt geloofwaardiger dan een bedrijf dat incidenten wegmoffelt.

Er schuilt ook een minder voor de hand liggend doel in: postmortems maken onzichtbare complexiteit zichtbaar. Grote technische systemen zijn vaak zo ingewikkeld dat niemand ze volledig overziet. Pas wanneer iets misgaat, wordt duidelijk hoe onderdelen op onverwachte manieren met elkaar samenhangen.

Voorbeelden uit de praktijk

Etsy en de blameless postmortem (rond 2012). De Amerikaanse webwinkelplatform Etsy geldt als een van de eerste bedrijven die de blameless-aanpak expliciet formuleerde en intern verankerde, met John Allspaw als belangrijk pleitbezorger. Zijn werk beïnvloedde hoe de hele softwaresector later over postmortems ging denken.

Google en de Site Reliability Engineering-praktijk (boek uit 2016). Google publiceerde in 2016 het boek "Site Reliability Engineering", vrij online beschikbaar, met een apart hoofdstuk over postmortemcultuur. Dit boek maakte het begrip wereldwijd gemeengoed binnen de techsector.

De AWS-storing van 2017. In februari 2017 viel een groot deel van Amazon Web Services' opslagdienst S3 urenlang uit in de regio die veel Amerikaanse websites gebruikt. De openbare postmortem van Amazon wees een menselijke fout aan: een engineer voerde tijdens onderhoud aan het facturatiesysteem een commando uit dat per ongeluk veel meer servers offline haalde dan bedoeld. De storing legde bloot hoeveel diensten op het internet indirect van één cloudleverancier afhankelijk waren.

De wereldwijde Facebook-uitval van 2021. In oktober 2021 waren Facebook, Instagram en WhatsApp zes uur lang wereldwijd onbereikbaar. De postmortem van het bedrijf (toen nog Facebook, inmiddels Meta) wees een configuratiewijziging aan het routeringsprotocol BGP aan als oorzaak, die er onbedoeld voor zorgde dat de eigen datacenters zichzelf van het internet afsneden — inclusief de systemen die nodig waren om het probleem op afstand te herstellen.

SpaceX en de Falcon 9-mislukking (2015). In juni 2015 explodeerde een Falcon 9-raket van SpaceX kort na lancering tijdens een bevoorradingsvlucht naar het internationale ruimtestation ISS. Onderzoek wees een gefaalde metalen steun (strut) in het heliumsysteem van de tweede trap aan als oorzaak. Dit soort onderzoeken naar mislukte lanceringen, inclusief recentere testvluchten van SpaceX' Starship-raket, volgen een vergelijkbare logica als softwarepostmortems, al werken luchtvaart- en ruimtevaartorganisaties vaak binnen formelere, door toezichthouders voorgeschreven kaders.

Hoe ver is de techniek?

Postmortemanalyse is geen technologie in de zin van hardware of algoritmes, maar een methodologie — en die is inmiddels breed verspreid binnen de techsector. Bij grote clouddiensten en softwarebedrijven is het een standaardonderdeel van wat "Site Reliability Engineering" of "DevOps" wordt genoemd. Er bestaat inmiddels gespecialiseerde software om incidentresponsen en postmortems te ondersteunen, van bedrijven als PagerDuty en incident.io, die helpen bij het vastleggen van tijdlijnen en het bewaken van actiepunten.

Toch is de praktijk verre van uniform. Bij veel kleinere organisaties ontbreekt tijd, discipline of cultuur om postmortems grondig uit te voeren; ze blijven dan steken in een kort mailtje in plaats van een diepgaande analyse. Ook bij grote bedrijven is een werkelijk "blameless" cultuur lastig te realiseren: onder druk van reputatieschade of juridische aansprakelijkheid neigen organisaties er soms toch toe verantwoordelijkheid af te schuiven, wat de eerlijkheid van interne rapportages ondermijnt.

Een recentere ontwikkeling is het gebruik van kunstmatige intelligentie om postmortems te ondersteunen: algoritmes die automatisch logbestanden doorzoeken, anomalieën signaleren of een eerste concepttijdlijn opstellen. Dit werk staat nog in een vroeg stadium en de resultaten moeten door mensen worden gecontroleerd; AI kan patronen missen die alleen duidelijk worden met domeinkennis, en kan ook ten onrechte oorzaken suggereren die slechts toevallig samenvallen met het incident.

Wie werken eraan?

Binnen de softwarewereld hebben vooral grote Amerikaanse techbedrijven de postmortemcultuur gevormd en verspreid: Google (met zijn invloedrijke SRE-boek), Etsy (pionier van de blameless-aanpak), Amazon/AWS, en Meta publiceren geregeld eigen postmortems, deels om verantwoording af te leggen aan klanten en toezichthouders. Gespecialiseerde bedrijven zoals PagerDuty en incident.io bouwen software die incidentbeheer en postmortems structureert.

Buiten de softwaresector bestaan er langer gevestigde, formelere tegenhangers. In de luchtvaart onderzoekt de Amerikaanse National Transportation Safety Board (NTSB) ongevallen volgens strikte, wettelijk verankerde procedures. NASA voerde na de Columbia-ramp van 2003 een uitgebreid onafhankelijk onderzoek uit via de Columbia Accident Investigation Board, met een rapport dat als schoolvoorbeeld geldt van grondige oorzaakanalyse bij complexe technische systemen. In de cybersecuritywereld geven overheidsinstanties zoals het Amerikaanse CISA en het Nederlandse Nationaal Cyber Security Centrum (NCSC) richtlijnen voor incidentonderzoek na digitale aanvallen, vaak aangeduid als "post-incident review".

Nederlandse en Europese organisaties volgen doorgaans dezelfde internationale praktijken, al is openbare publicatie van postmortems hier minder gebruikelijk dan bij Amerikaanse techbedrijven; veel Europese bedrijven behandelen incidentrapporten als intern of vertrouwelijk document.

Verder lezen