Post-Mortem Timeline Record
Construct forensic chronologies of infrastructure outages, record root-cause five-whys analysis, and track preventive action items.
Template Overview
A blameless post-mortem transforms an operational failure into durable organizational learning. The Post-Mortem Timeline Record template structures an exact chronological sequence of events, isolates technical root causes using the five-whys framework, and establishes auditable preventive safeguards.
Markdown Template Structure
Copy the block below or click Download .md File to add this template directly to your personal vault:
---
title: "Incident Post-Mortem: [INC-XXXXX Outage Title]"
date: [YYYY-MM-DD]
incident_commander: "[[Commander Name]]"
lead_investigator: "[[Reliability Engineer]]"
incident_date: "[YYYY-MM-DD]"
severity: "Sev-1 / Production Interruption"
customer_downtime_minutes: 42
tags: [post-mortem, sre, devops, incident-analysis, blameless]
---
# Incident Post-Mortem: [INC-XXXXX Outage Title]
## 1. Executive Summary & Blast Radius
- **Incident Overview:** At 14:12 UTC, European edge workers began throwing 502 Bad Gateway errors due to an unhandled memory threshold exception in the connection router.
- **Impact Duration:** 42 minutes (14:12 UTC to 14:54 UTC).
- **User Impact:** Approximately 2,400 active client sessions experienced dropped audio streaming connections.
- **Data Integrity:** Confirmed 0 data loss and 0 unencrypted data egress.
## 2. Chronological Timeline of Events
| Timestamp (UTC) | Source / Observer | Event Description |
|---|---|---|
| **14:05** | GitHub Actions | Deployment of edge worker bundle `v1.8.4` initiated. |
| **14:12** | PagerDuty | Canary alert triggers: p99 latency exceeds 4,000ms threshold. |
| **14:18** | [[Reliability Lead]] | Incident commander convenes emergency triage bridge. |
| **14:26** | [[Systems Architect]] | Traffic routed to redundant secondary edge cluster. |
| **14:41** | [[Engineer Name]] | Hotfix patch compiled and deployed to canary ring. |
| **14:54** | Monitoring | Error rates return to baseline 0.01%; incident resolved. |
## 3. Root Cause Analysis (Five Whys)
1. **Why did the edge workers fail?** Memory consumption exceeded the 128MB worker limit.
2. **Why was memory exceeded?** A large regex buffer failed to release pooled strings between requests.
3. **Why did the regex fail to release?** A closure retained a circular reference to the global response context.
4. **Why was this not caught in staging?** Staging automated tests only executed single-request payloads without concurrency.
5. **Why were concurrent load tests omitted?** CI/CD pipeline lacked an automated load stress testing stage.
## 4. Preventive Action Items & Safeguards
- [ ] [[Reliability Engineer]] Implement automated k6 concurrency stress test in staging CI (Deadline: Next Sprint).
- [ ] [[Systems Architect]] Refactor edge string parsing to use zero-allocation streaming iterators.
- [ ] [[Operations Lead]] Lower PagerDuty memory alert threshold from 90% to 75% for earlier detection.
Filled Real-World Example
Here is a realistic example demonstrating how this template captures actual deliberations:
---
title: "Post-Mortem: INC-701 Audio Buffer Stall"
date: 2026-10-07
incident_commander: "[[Marcus Vance]]"
lead_investigator: "[[Devin Zhao]]"
severity: "Sev-2"
tags: [post-mortem, sre, devops]
---
# Post-Mortem: INC-701 Audio Buffer Stall
## 1. Summary
A 15-minute audio capture freeze occurred when users connected certain external USB DACs running non-standard 44.1kHz sample rates alongside 48kHz microphones.
## 2. Root Cause
The CoreAudio sample rate converter lacked a fallback resampler for non-integer sample rate ratios.
## 3. Resolution
Devin Zhao shipped an updated vDSP linear interpolation resampler that transparently converts all input audio streams to 16kHz for Whisper inference.
When to Use and When to Avoid
When to Use
- Use within 48 hours following any Sev-1 or Sev-2 production system interruption.
- Use during blameless post-mortem retrospective meetings with engineering stakeholders.
- Use to establish auditable engineering accountability and preventive code safeguards.
When to Avoid
- Avoid using during the live crisis (use the live Incident Command Briefing template).
- Avoid using to assign personal blame or punitive performance evaluations.
On-Device AI Integration
Summarize your recording in Oyma with this local instruction:
Analyze the incident post-mortem recording:
1. Reconstruct a chronological timestamped sequence of events from alert trigger to resolution.
2. Summarize the five-whys root cause analysis agreed upon by the engineering team.
3. Extract all preventive action items, assigned engineering owners, and verification deadlines into Markdown.
Your data remains securely on your Mac with zero cloud exposure.
Frequently Asked Questions
Why is an accurate chronological timeline critical for post-mortems?
Timelines reveal time-to-detect (TTD) and time-to-resolve (TTR) gaps, showing whether monitoring, alerts, or runbooks caused downtime delays.
How does this template foster a blameless culture?
The five-whys analysis focuses systematically on process, tooling, and architectural safeguards rather than individual engineer errors.
Can sensitive outage post-mortems stay internal?
Because notes reside entirely on your local Mac disk in Markdown, sensitive security reviews are never indexed by external cloud services.
Write post-mortem timeline record in plain Markdown.
Store notes in your local vault, transcribe meetings on-device, and retain 100% data sovereignty.