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 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:
Each of these is a hard writing task under normal circumstances. At 2am after an incident they're brutal.
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.
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
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
What Went Well
What Did Not Go Well
Action Items
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.
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.
Once I built the postmortem prompt, I realized the same approach applied to every painful writing task in SRE work:
The pattern is the same every time: give the AI your raw material and a structured prompt, get professional output in under 5 minutes.
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.