Templates · Executive summaries
Project Post-Mortem One-Pager Template
This post-mortem one-pager template carries everything a reader needs from an incident review — what it cost, what happened minute by minute, why, and who owns the follow-ups — on a single page, packed tightly because an incident review genuinely has several sections that all matter and none that can be cut.
What this card carries
- Impact quantified first: duration, affected sessions, failed orders, estimated revenue
- A timeline on real timestamps — deploy at 09:12, first signal from support at 09:31
- A root cause stated as a contract mismatch rather than a person's mistake
- The systemic failures separated from the cause: alerting gap, runbook gap, unclear ownership
- A remediation plan with a due date on every action
The incident write-up this page was generated from
Post-mortem — checkout outage, 14 March
Impact. Checkout was unavailable or degraded for 3 hours 42 minutes. Approximately 8,400 sessions hit an error at payment; 611 orders failed outright. Estimated lost revenue 74,000 dollars. Support handled 230 tickets over two days.
Timeline. 09:12 a routine config deploy raises the connection-pool ceiling on the payments service. 09:14 pool saturation begins; latency climbs but stays inside alert thresholds. 09:31 the first customer report arrives via support, not monitoring. 09:58 an engineer correlates the report with the deploy. 10:20 rollback starts. 10:44 rollback completes but the pool does not recover because stale connections are held open. 12:10 the service is restarted and traffic normalises. 12:54 incident closed.
Root cause. The config change was valid in isolation but exceeded the database's own connection limit, so the pool acquired connections the database silently refused to serve. No single component was misconfigured; the ceiling was raised on one side of a contract that only the other side enforced.
What went wrong beyond the cause. Alerting watched error rate but not saturation, so a 17-minute head start was lost. The runbook assumed rollback was sufficient and did not mention connection draining. Ownership of the payments pool was ambiguous between two teams.
What went right. Rollback tooling worked exactly as designed. The support-to-engineering escalation path was fast once triggered. No data was lost or double-charged.
Actions. Add saturation alerts on all pooled resources, owner platform, due 28 March. Encode the database connection ceiling as a validated bound on the config, owner payments, due 4 April. Rewrite the runbook to include draining, owner payments, due 21 March. Assign single-team ownership of the payments pool, owner engineering leadership, due 21 March.
Why this post-mortem one-pager template uses dense modules
A post-mortem is tempting to draw as a timeline, since the timeline is its most vivid part. But a timeline-only page answers "what happened" and silently drops the three things a reader actually needs next: what it cost, why it happened, and what changes as a result.
Dense modules keep all four on one page without implying a single sequence. The reader can go straight to the actions block if that is their job, or read the timeline if they are trying to understand the failure — which is how these documents are genuinely used.
Blameless, and still specific
The root cause here is written the way good retros write them: the config change was valid in isolation and exceeded a limit only the other side of the contract enforced. No component was misconfigured and no individual was careless — the failure lived in the gap between two systems' assumptions.
That framing survives into the visual because the visual is generated from it. A one-pager built from blameless prose reads as blameless; one assembled by hand from a template tends to drift toward whoever is filling the boxes.
- Incident and outage reviews
- Project retrospectives at milestone close
- Programme status where a decision is needed
- Launch readiness sign-offs
Questions
Questions about this executive summary template
No. It is a realistic but fictional write-up, built so the example shows what a full post-mortem looks like end to end without exposing anyone's actual outage.
Dates reliably do — this example carries a due date on every action. Owners are less certain: the source text named a team per action and this render dropped them in favour of the action itself. If ownership must appear, put it in the action's own sentence rather than as a trailing attribution.
As the front page of it, not as a replacement. It carries enough — impact, timeline, cause, actions — for someone who was not involved to understand what happened. Anyone who has to act on a finding still needs the full document, so point at it from the same email.
More executive summary & one-pager templates
Use this template with your own text
Paste your content and this template's structure, style, aspect and palette are applied for you. One credit per image, and the first is free.