Originally published on Medium
It's 2:51am. The incident is resolved. Error rate is back to zero, the rollback worked, and your on-call pager has finally gone quiet.
Now you have to write the postmortem.
If you've been in SRE or DevOps for any length of time, you know this feeling. You're exhausted, your brain is running on adrenaline fumes, and somewhere in the back of your mind you know that what you write in the next hour is going to be read by engineers, product managers, and probably a VP or two. It needs to be clear, blameless, specific, and actionable.
Most of us write it badly. Not because we're bad at our jobs — because we're human beings who just spent two hours firefighting and now we're staring at a blank document at 3am trying to remember the exact sequence of events.
There's a better way.
The Problem With How We Write Postmortems
The standard postmortem template is a solved problem. Every company has one. Timeline, root cause, contributing factors, action items — we all know the structure.
The hard part isn't the structure. It's the writing.
Specifically:
- Reconstructing the timeline from a chaotic Slack thread where half the messages are noise
- Writing the root cause narrative in plain language when your brain is still in technical mode
- Generating action items that are actually specific and assignable instead of vague gestures toward improvement
- Translating all of it into an executive summary that a non-technical VP can understand without losing the technical accuracy
Each of these is a hard writing task under normal circumstances. At 2am after an incident they're brutal.
What Changed for Me
I started treating postmortem writing like any other repetitive engineering task: I built a system for it.
Specifically, I built a set of AI prompts designed for the exact scenarios SREs face. Not generic "write me a postmortem" prompts — structured prompts that work with the raw material you actually have in front of you at the end of an incident.
The key insight was that the problem isn't AI capability. ChatGPT and Claude are perfectly capable of writing a professional postmortem. The problem is that a vague prompt produces a vague output. "Write a postmortem for a database outage" gives you a generic template you could have Googled.
What actually works is a prompt that tells the AI exactly what you're giving it, exactly what format you want, and exactly what constraints to follow. And critically — a prompt that works with your raw Slack thread, not a cleaned-up version you had to spend 20 minutes organizing first.
The Before and After
Here's a real example of what this looks like in practice.
What you paste in (your raw material):
oncall-eng 2:14 AM: pagerduty firing on api-gateway, looks bad
sre-lead 2:17 AM: checking, 503s on /checkout endpoint, 40% error rate
db-eng 2:19 AM: is this related to the deploy we did?
sre-lead 2:31 AM: found it — connection pool exhausted after config change in v2.3.1
oncall-eng 2:44 AM: rolled back, error rate dropping
sre-lead 2:51 AM: all clear. ugh need to write the postmortem now
The prompt:
I am going to paste my incident notes and timeline. Write a complete
blameless postmortem. Include: incident summary, timeline of events,
root cause, contributing factors, customer impact, what went well,
what did not, and 3-5 specific actionable action items with owners
and due dates. Tone: analytical, not finger-pointing.
Here is my source material: [paste notes, timeline, or Slack thread]
What you get back (in about 60 seconds):
Incident Summary
A connection pool exhaustion caused a 40% error rate on /checkout for 37 minutes, affecting an estimated 8,400 users during peak traffic.
Timeline
- 02:14 — PagerDuty alert fires on api-gateway
- 02:17 — 503s confirmed on /checkout, 40% error rate
- 02:31 — Root cause identified: connection pool exhausted after v2.3.1 config change
- 02:44 — Rollback initiated, error rate recovering
- 02:51 — Incident resolved, all systems nominal
Root Cause
The v2.3.1 configuration change reduced the connection pool limit from 100 to 10, insufficient for peak traffic load. The change was not caught in staging due to lower traffic volume in that environment.
Contributing Factors
- Staging environment does not mirror production traffic patterns
- No alerting existed on connection pool utilization
- Config change review process did not include load impact assessment
What Went Well
- On-call response time was under 3 minutes from alert to acknowledgment
- Root cause was identified within 17 minutes
- Rollback was clean and effective
What Did Not Go Well
- No connection pool utilization alerts meant the issue wasn't detected until user impact
- Staging environment gap allowed a configuration error to reach production
Action Items
- Add connection pool utilization alerts at 70% and 90% thresholds — Owner: SRE team — Due: 1 week
- Mirror production traffic patterns in staging environment — Owner: Platform team — Due: 2 weeks
- Add connection pool impact to config change review checklist — Owner: Engineering Lead — Due: 1 week
- Document connection pool sizing guidelines for future deployments — Owner: SRE Lead — Due: 2 weeks
That took 60 seconds to generate from a messy Slack thread. Editing it to your specific details takes another 2 minutes. Total time: under 5 minutes for a complete, professional postmortem.
Compare that to the 45-60 minutes most engineers spend on this task, late at night, running on empty.
Why Two Formats Matter
One thing I learned building this system: there are two different situations you find yourself in at the end of an incident.
Situation 1: You have raw material — a Slack thread, PagerDuty alerts, your own notes. You just need someone to transform it into a professional document. This is the paste-in scenario above.
Situation 2: You're mid-incident and too overwhelmed to organize your thoughts. You don't have notes, you have a spinning brain and a lot of adrenaline.
For situation 2, the paste-in prompt doesn't work. What works is an interview format — a prompt that tells the AI to ask you questions one at a time until it has enough to write the postmortem without you having to organize anything first.
I need to write a postmortem but have not organized my notes yet.
Ask me questions one at a time to gather: timeline, root cause,
contributing factors, impact, what went well, and what did not.
When you have enough, write the full blameless postmortem with
3-5 specific action items.
You answer one question at a time. The AI assembles the postmortem. You don't have to think about structure at all.
This Isn't Just Postmortems
Once I built the postmortem prompt, I realized the same approach applied to every painful writing task in SRE work:
- Incident communications — initial notifications, status page updates, executive Slack messages, customer-facing resolution notices
- Runbooks — generating them from scratch, improving existing ones, converting Slack incident threads into reusable documentation
- On-call documentation — shift handoffs, escalation matrices, on-call health reports for leadership
- Engineering leadership writing — headcount proposals, technical debt proposals, engineering principles documents, all-hands updates
- Observability — alert definition documents, dashboard documentation, SLI selection for new services
The pattern is the same every time: give the AI your raw material and a structured prompt, get professional output in under 5 minutes.
The Full System
I packaged everything I built into The SRE Prompt Pack — 68 prompts across 7 sections, each in both paste-in and interview format.
It also includes 5 workflow chains that show you how to run prompts in sequence for complete end-to-end documentation. The incident lifecycle chain takes you from raw Slack thread to timeline, impact statement, full postmortem, and executive summary in about 30 minutes.
Works with Claude, ChatGPT, Gemini, or any LLM you use at work.
I built this — The SRE Prompt Pack — 68 prompts, 41 pages, $29.
Top comments (0)