The Blameless Postmortem: Turn an Outage Into a Clear RCA

Why the RCA Is the Worst Part of an Incident

The fire is out. The system is back. You've been awake for hours. Now comes the part everyone dreads: the Root Cause Analysis — written exhausted, on a deadline, with the quiet fear that the document will be used to find someone to blame.

In Indian IT and services the stakes are higher still. The RCA isn't just an internal note; it often goes to the client, ties to an SLA, and lands on your reporting manager's desk. So it has to be accurate, readable by a non-technical stakeholder, and it cannot read like you're throwing a teammate under the bus.

AI is genuinely good at this — not at finding the cause for you, but at taking the messy raw material you already have and shaping it into the structure a great postmortem needs. To do that well, you have to give it the right structure. Most people give it the wrong one.

The Mistake Everyone Makes: Hunting for The Root Cause

The instinct is to ask "what was the root cause?" and write down one thing: the bad deploy. That's the single biggest weakness in most RCAs, and the world's most mature incident teams have moved past it.

Google's SRE postmortem practice is explicit: a serious incident almost never has one root cause. It has contributing factors — usually two to five systemic ones. The bad config was the trigger, yes. But why did it reach production? No guardrail on the connection pool. Why wasn't it caught? The pre-deploy checks didn't cover that failure mode. Why did it take 40 minutes to spot? No alert on the right metric. Each of those is a separate, fixable systemic gap — and each one you name is a future outage you prevent.

This is also what makes a postmortem blameless: when you list systemic factors instead of "Rahul pushed bad config," you're describing conditions a competent person walked into, not a person who failed. Google's principle is to assume everyone acted with the best information they had at the time. Blame kills the honesty that makes postmortems useful; systems thinking keeps it. So the prompts below tell AI to do two things most people don't: find multiple contributing factors, and frame every one as a system gap, not a human mistake.

Rule Zero: Sanitize Before You Paste

Read this first, because incident data is some of the most sensitive data you touch. Never paste raw production logs, stack traces containing secrets, customer data, API keys, internal hostnames, or client names into a free or public AI tool. Strip credentials, mask customer identifiers, replace the client's name with "the client." On a Team or Enterprise plan with a privacy guarantee you have more room — but when in doubt, sanitize or check with your security team first. An RCA that leaks data is a second incident.

The Prompts

Each prompt below follows the same shape — Role (who the AI should be), Task (what to do), Context (your situation and rules), and an Example when the format matters. That structure is what reliably gets a usable answer instead of a vague one.

1. The Structurer

A strong postmortem answers five questions: what happened, why, how we responded, what we learned, what we'll change. Make AI map your notes onto exactly that.

Role: You are an experienced site reliability engineer who writes blameless postmortems in the Google SRE style.
Task: Organize my raw, sanitized notes into these sections:
1. Summary — 2 sentences a non-technical manager can understand.
2. Impact — who/what was affected, for how long, severity (users, SLA).
3. Timeline — detection, diagnosis, mitigation, resolution, with timestamps.
4. Contributing Factors — 2 to 5 SYSTEMIC factors (not one root cause), each framed as a process/system gap, never a person's mistake.
5. What Went Well.
6. Action Items — each with an [owner] and [due date] placeholder.
Context: If a fact is missing from my notes, write "[NEEDS CONFIRMATION]" — never guess a timestamp, number, or cause.
My sanitized notes: [PASTE]

2. The Contributing-Factors Finder

If your draft names only one cause, widen it:

Role: You are an incident analyst who knows serious outages never have a single root cause.
Task: Given my current root cause below, identify the OTHER contributing factors that had to line up for this incident to happen AND to last as long as it did — think trigger, missing guardrail, detection gap, and response delay. For each, phrase it as a systemic gap we can fix, and suggest the action item that closes it.
Context: My current (single) root cause: [PASTE]

3. The Blame Stripper

Role: You are an editor who enforces blameless postmortem culture.
Task: Rewrite the draft below to be strictly blameless. Replace any phrasing that blames a person ("X forgot to...", "Y pushed bad code") with system-focused language ("the deploy process allowed...", "there was no check that..."). Remove hindsight phrasing like "should have known"; describe what was reasonable given the information available at the time. Keep every fact identical.
Context: This will be read by the people who were involved in the incident.
Example:
  Before: "Rahul forgot to add a connection-pool limit."
  After: "There was no guardrail requiring a connection-pool limit on this change."
Draft: [PASTE]

4. The Exec Summary

Role: You are a delivery lead briefing a non-technical reporting manager or client.
Task: Write a 4-sentence summary of this incident: what happened, the business impact, that it's resolved, and that we have a plan to prevent recurrence. No jargon.
Context: The reader cares about customer impact and reassurance, not technical detail.
Incident details: [PASTE]

Before and After

Your raw notes:

AI output — Contributing Factors (blameless, plural):

Four fixable gaps instead of "the deploy broke it." Notice no name appears anywhere — only what the system allowed.

When NOT to Trust the AI Blindly

• It will invent a confident, wrong cause. AI is a pattern-matcher; it'll produce a professional-sounding contributing factor that isn't real. You verify each one against the actual logs and facts — the same discipline as stopping AI hallucinations in reports.
• Never let it guess numbers or timestamps. If your notes don't contain it, it must say "[NEEDS CONFIRMATION]."
• The action items are yours to own. AI can propose fixes; assigning owners and dates is a human decision — and a postmortem with no follow-through breeds cynicism faster than no postmortem at all.

Which AI Does This Best?

• Claude handles long, messy input and holds the blameless, systemic tone across a full document — strong for the structuring pass.
• ChatGPT is good, and its data-analysis mode helps if you have a clean, sanitized metrics table to summarize.
• Either way: structure in one chat, and keep your sanitized notes in a separate doc you control.

Why I Wrote This

I'll be honest: I don't get paged at 2am to fix outages — I'm an automation consultant, not an on-call engineer. This section of the site exists because a software engineer I trust pointed out there was nothing here for the work he actually does.

So I didn't make up the method. The "contributing factors, not a single root cause" model and the blameless principle come straight from how Google's SRE teams run postmortems — the most battle-tested incident practice there is — and I shaped the prompts around that, then tested them.

What I have seen up close, in consulting, is how a calm, well-structured write-up of a failure changes everything about how it lands with a manager or a client. If this turns your next RCA from a dreaded blank page into a fifteen-minute review, it did its job.