Een incident-postmortem is een korte schriftelijke evaluatie van een storing: wat er gebeurde, wat het voor gebruikers betekende, waarom het gebeurde en wat je verandert zodat het niet opnieuw gebeurt. Een blameless postmortem richt zich op systemen en processen, niet op wie er een fout maakte. Het basistemplate heeft zes onderdelen: samenvatting, impact, tijdlijn, hoofdoorzaak, wat goed en wat slecht ging, en actiepunten met eigenaren en deadlines.
Hieronder lees je wanneer je er een schrijft, welke principes hem nuttig houden, een volledig template om te kopiëren, een ingevuld voorbeeld en hoe je er een samenvatting voor klanten van maakt.
Wanneer schrijf je een postmortem?
Niet elke hapering verdient een document. Leg duidelijke triggers vast, zodat je die beslissing niet onder druk hoeft te nemen. Veelgebruikte triggers:
Klanten konden een kernfunctie, zoals afrekenen, inloggen of de API, langer dan een paar minuten niet gebruiken.
Er zijn gegevens verloren gegaan, beschadigd of uitgelekt.
Het incident heeft een groot deel van je maandelijkse error budget opgebruikt.
Klanten of een opdrachtgever meldden het probleem eerder dan je monitoring.
Hetzelfde soort incident is al eerder voorgekomen.
Schrijf hem binnen een paar werkdagen, zolang herinneringen en logs nog vers zijn. Een postmortem die drie weken later wordt geschreven, is grotendeels giswerk.
Blameless principes
Een blameless postmortem gaat ervan uit dat iedereen redelijk handelde met de informatie die er op dat moment was. Als één persoon de site met één commando plat kon leggen, dan is het probleem dat één commando de site plat kon leggen. Schuld zoeken zorgt ervoor dat mensen details verzwijgen, en juist die details heb je nodig.
Beschrijf handelingen, geen personen. “De importjob werd tijdens de piekuren gestart” in plaats van “Anna startte de import op het verkeerde moment”.
Vraag “hoe”, niet “wie”. Hoe kon het systeem dit toelaten? Hoe kwamen we erachter? Hoe hadden we er eerder achter kunnen komen?
Zoek naar meerdere oorzaken. Incidenten hebben zelden één hoofdoorzaak. Meestal treft een trigger een zwakke plek die een ontbrekende waarborg niet opving.
Gebruik feiten en tijdstempels. Monitoringdata, logs en chatgeschiedenis zijn betrouwbaarder dan het geheugen.
Houd de actielijst kort. Twee of drie veranderingen die echt worden doorgevoerd, zijn beter dan tien die blijven liggen.
Het postmortem-template
Kopieer dit naar je wiki, repository of documenttool. Elke kop heeft een aanwijzing voor wat erbij hoort.
# Postmortem: [korte titel]
Datum incident: [JJJJ-MM-DD]
Auteur(s): [namen]
Status: [concept / in review / definitief]
Ernst: [bijv. SEV1 / SEV2 / SEV3]
## Samenvatting
[Twee of drie zinnen: wat er kapot ging, hoe lang en hoe het is opgelost.]
## Impact
– Getroffen services en onderdelen:
– Duur (begin tot herstel):
– Getroffen gebruikers of klanten:
– Zakelijke impact (bestellingen, aanmeldingen, SLA):
– Klantcommunicatie (statuspagina, e-mails, tickets):
## Detectie
– Hoe werd het incident ontdekt? (monitor, klant, teamlid)
– Tijd van begin tot alarm:
– Tijd van alarm tot bevestiging:
## Tijdlijn
[Alle tijden in één tijdzone. Eén regel per gebeurtenis.]
HH:MM gebeurtenis
HH:MM gebeurtenis
## Hoofdoorzaak en bijdragende factoren
– Trigger:
– Onderliggende oorzaak:
– Waarom de waarborgen het niet opvingen:
## Oplossing
[Wat er is gedaan om de dienst te herstellen, en door wie (rol, geen schuld).]
## Wat ging goed
–
## Wat ging slecht
–
## Waar we geluk hadden
–
## Actiepunten
| Actie | Type (voorkomen / detecteren / reageren) | Eigenaar | Deadline | Ticket |
|——-|——————————————|———-|———-|——–|
| | | | | |
## Samenvatting voor klanten
[Korte versie voor de statuspagina of een e-mail aan klanten.]
Het onderdeel “Waar we geluk hadden” sla je gemakkelijk over, terwijl het vaak het waardevolst is. Het legt de bijna-ongelukken vast: het incident gebeurde ’s nachts, de back-up was een uur eerder gedraaid, de enige persoon die het systeem kende was toevallig wakker.
Een ingevuld voorbeeld
Hier is het template toegepast op een fictief incident bij een webshop, northwind.shop. De details zijn ter illustratie verzonnen, maar de opbouw is zoals een echte postmortem eruit hoort te zien.
Samenvatting
Van 03:12 tot 03:19 CET gaf de checkout van northwind.shop 503 Service Unavailable terug. Een nachtelijke productimport gebruikte alle PHP-FPM-workers, waardoor checkout-verzoeken werden geweigerd. De developer met dienst stopte de import en herstartte PHP-FPM. Totale downtime: 7 minuten.
Impact
Checkout en winkelwagen waren 7 minuten niet beschikbaar. Productpagina’s werden uit de cache geserveerd en bleven up.
De serverlogs tonen in die periode 23 mislukte checkout-verzoeken (voorbeeldcijfer).
De statuspagina toonde vanaf 03:13 “Checkout: major outage”. Er kwamen geen supporttickets binnen.
Tijdlijn
03:00 De nachtelijke productimport start.
03:12 De uptimecheck op northwind.shop/checkout geeft 503 terug.
03:13 Een tweede check bevestigt de fout. Er wordt een incident geopend, de developer met dienst krijgt een alarm via Telegram en de details worden in het Slack-kanaal van het team geplaatst. De statuspagina markeert Checkout als down.
03:15 De dienstdoende bevestigt in Slack en opent het serverdashboard. Geheugen en CPU zijn hoog op web-01.
03:17 De PHP-FPM-status toont dat alle workers bezig zijn met importverzoeken. De importjob wordt gestopt.
03:18 PHP-FPM wordt herstart.
03:19 De checks slagen weer. Er gaat een herstelmelding uit met een totale downtime van 7 minuten.
Hoofdoorzaak en bijdragende factoren
Trigger: de feed van de leverancier was na een catalogusupdate drie keer zo groot als normaal.
Onderliggende oorzaak: de import draait via dezelfde PHP-FPM-pool als de shop. Grote imports kunnen alle workers opgebruiken.
Ontbrekende waarborg: de import heeft geen limiet op gelijktijdige verzoeken, en er was geen alarm op volgelopen workers.
Achtergrond over waarom uitgeputte workers juist deze fout opleveren, lees je in onze gids over de 503 Service Unavailable-fout.
Wat goed ging, wat slecht ging en waar we geluk hadden
Goed: detectie duurde één minuut en bevestiging twee. De statuspagina werd bijgewerkt zonder handwerk.
Slecht: het vinden van de oorzaak duurde vier minuten, omdat niets de importjob aan de webservers koppelde.
Geluk: het gebeurde om 03:12, niet tijdens de avondpiek.
Actiepunten
ActieTypeEigenaarDeadlineDraai de import in een aparte worker-pool met een limiet op gelijktijdigheidVoorkomenBackend leadBinnen 2 wekenAlarm wanneer het geheugen van web-01 boven 85% blijftDetecterenOpsDeze weekVoeg een heartbeat toe die meldt wanneer de import klaar isDetecterenBackend leadDeze weekVoeg het runbook “503 op checkout” toe aan de monitorReagerenOn-call-rotatieDeze week
Een samenvatting voor klanten publiceren
De interne postmortem is voor het team. Klanten hebben een kortere versie nodig zonder servernamen: wat er gebeurde, hoe lang, of hun gegevens veilig zijn en wat je verandert. Plaats die op je statuspagina en link ernaar vanuit elke incidentmail of update aan klanten. In Uptimecheck schrijf je de incidentevaluatie bij het incident zelf, naast de tijdlijn, en kun je ervoor kiezen die onder het incident op je statuspagina te tonen.
Afrekenen niet beschikbaar, 03:12 tot 03:19 CET
Tussen 03:12 en 03:19 CET konden klanten geen aankopen afronden op
northwind.shop. Producten bekijken werkte gewoon, en er zijn geen
bestellingen of betaalgegevens verloren gegaan.
De oorzaak was een geplande productupdate die meer servercapaciteit
gebruikte dan verwacht. We hebben die gestopt, en het afrekenen werkte
om 03:19 weer.
We verplaatsen deze updates naar aparte capaciteit, zodat ze het
afrekenen niet meer kunnen raken, en we hebben eerdere waarschuwingen
voor dit soort belasting toegevoegd.
Houd de toon feitelijk en de beloftes concreet. “We nemen betrouwbaarheid serieus” zegt niets; “imports draaien nu op aparte capaciteit” zegt wel iets. Onze gids over een statuspagina maken gaat dieper in op de formulering van incidentupdates.
Het helpt ook om te weten hoeveel mensen het merkten. Uptimecheck levert bij elke statuspagina statuspagina-analytics, met bezoeken per dag en per land, verwijzer en apparaat over de laatste 30 dagen, zodat je in de postmortem kunt opnemen hoeveel mensen de pagina op de dag van het incident bekeken. Samen met de incidenttijdlijn heb je dan begin, alarm, bevestiging, herstel en bereik, zonder door logs te hoeven spitten. Website-incidenten bevatten ook de foutieve response, met een screenshot of een traceroute, een goed startpunt voor de onderdelen over detectie en hoofdoorzaak.
Actiepunten opvolgen
Een postmortem zonder afgeronde actiepunten is een verhaal, geen oplossing. Behandel de acties als elk ander werk:
Maak voor elke actie een ticket aan in de tracker die het team al gebruikt, en link ernaar vanuit de postmortem.
Geef elke actie één eigenaar en een deadline.
Label acties per type: voorkomen, detecteren of reageren. Is elke actie “beter opletten”, dan was de evaluatie niet af.
Bespreek openstaande postmortem-acties in een vast overleg, bijvoorbeeld elke twee weken.
Markeer de postmortem pas als definitief wanneer alle acties zijn afgerond of bewust, met een reden, zijn geschrapt.
Na verloop van tijd worden de postmortems zelf data. Tel hoeveel incidenten door monitoring werden gevonden en hoeveel door klanten, en volg de detectie- en reactietijden van incident tot incident. Ons artikel over MTTR, MTTA en MTBF legt uit hoe je ze berekent.
Het evaluatieoverleg leiden
Bij grotere incidenten helpt een overleg van 30 tot 45 minuten. Deel het concept vooraf, laat degene die de respons leidde de tijdlijn doorlopen, en besteed de meeste tijd aan bijdragende factoren en acties. Een neutrale gespreksleider die niet aan het incident heeft gewerkt, houdt het gesprek blameless en binnen de tijd. Sluit af door per actiepunt de eigenaar en deadline te bevestigen.
Krijg de tijdstempels voor je volgende postmortem automatisch. Probeer Uptimecheck 14 dagen gratis, geen creditcard nodig.