Why You Shouldn't Use LLMs to Write Incident Post-Mortems (And the Ethical Way to Document Technical Failures)

We’ve all been there. It’s 3:00 AM, a poorly planned database migration has just dropped your production cluster, and you’ve spent the last four hours mainlining espresso to patch the schema and bring the site back online. By sunrise, the system is stable, but the real dread is just beginning: management wants a blameless post-mortem on their desks by close of play.

Your eyes are burning, your brain is mush, and the temptation is incredibly high to dump the raw Slack incident channel transcripts and terminal logs into Claude or ChatGPT, type “write a professional, blameless post-mortem of this outage,” and hit export.

It feels like a victimless shortcut. After all, the incident is over, the code is fixed, and post-mortems are just administrative red tape, right?

Wrong. Offloading the narrative of a technical failure to an LLM is a fundamental mistake—both practically and ethically. It sanitises the messy human reality of software engineering, breaks the feedback loops that prevent future outages, and abdicates your collective responsibility to your users and your team.

The Illusion of "Narrative Neatness"

LLMs are trained to predict the most statistically probable next token. By their very nature, they strive for narrative neatness, coherence, and resolution. But software outages are rarely neat, and they are almost never coherent in real time.

An outage is a socio-technical event. It is a complex web of outdated documentation, alert fatigue, human exhaustion, shifting priorities, and system quirks. When you feed a chaotic timeline of Slack messages and terminal commands into an AI, the model will naturally smooth out the rough edges to create a professional-sounding report. It will bridge gaps in the timeline with plausible-sounding assumptions and downplay the moments of confusion or panic.

In doing so, it hides the exact information you actually need to fix. If the AI reports that "the engineering team promptly identified the root cause in the Redis cache," it masks the uncomfortable truth: that your team spent two hours looking at the wrong Grafana dashboard because the correct one was broken. The AI prioritises a clean output over the messy, uncomfortable truths that reveal what actually makes your system tick.

The Danger of Hallucinated System Architectures

When an LLM is asked to write an incident report based on incomplete logs, it fills in the blanks. It doesn't tell you, "I don't have enough context to understand why the database pool exhausted its connections." Instead, it draws on its training data to invent a highly convincing, highly plausible explanation.

If you copy-paste this explanation into your official engineering records, you are now committing fictional system architecture to your team’s long-term memory. Future engineers—who weren't awake at 3:00 AM during the incident—will read that post-mortem, take the LLM's hallucinated explanation as gospel, and design future systems or runbooks based on a false premise. You aren't just failing to learn from the current incident; you are actively poisoning the well for future troubleshooting.

The Ethics of Abdicated Responsibility

At its heart, a post-mortem is an act of accountability. It is a promise to your customers, your stakeholders, and your colleagues that you respect their time, their data, and their trust enough to sit with your mistakes and understand them.

When you use an AI to ghostwrite this reflection, you are saying that the intellectual and emotional labour of reflecting on a failure isn’t worth your time. If your team didn't write the post-mortem, your team hasn't actually processed what happened. The psychological safety required for a truly "blameless" culture is built on vulnerability and honesty. Outsourcing your remorse and your analysis to a corporate-toned API is the antithesis of that culture.

How to Use AI Ethically in the Post-Mortem Process

This doesn't mean AI has no place in the aftermath of an outage. When used as a structured processing tool rather than a narrative author, LLMs can save you hours of manual formatting. Here is how to draw that ethical line:

• Do use AI to standardise timelines: Give the AI your raw, messy Slack timestamps and ask it to output a chronological Markdown list. This is a mechanical task that LLMs excel at. (If you run into token-limit issues with massive logs, check out our troubleshooting guides over at the Claude articles hub).
• Do use AI to categorise raw logs: You can ask an LLM to parse a wall of system logs and pull out only the unique error codes or specific IP addresses to save you searching manually.
• Never let the AI write the "Why It Happened" section: The root cause analysis must be written by the humans who built and operate the system. If you can't explain it yourself, you don't understand it yet.
• Never let the AI write the "Action Items": Preventative measures must be realistic, bound to human owners, and reflective of your actual team capacity—something an LLM cannot judge.

The Human-Led Post-Mortem Blueprint

To keep your post-mortems authentic, effective, and ethically sound, stick to this simple, human-centric pipeline:

1. The Chronology (Semi-Automated): Use an LLM to clean up your raw incident channels into a clean timeline of events.
2. The Live Review (All Human): Get the key responders on a call or in a room. Walk through the timeline. Ask the hard, uncomfortable questions: Who was tired? Did the alerts work? Why did we make that assumption?
3. The Narrative (All Human): Write the summary in plain, direct language. Do not try to make yourselves look smart. Write as if you are explaining the outage to a new junior engineer joining the team next week.
4. The Actions (All Human): Write down concrete, small, achievable tickets.

Writing a post-mortem should feel slightly uncomfortable. It requires you to confront the limitations of your system and your own knowledge. That discomfort is not a bug to be bypassed with a prompt; it is the exact mechanism by which we grow as engineers.