The incident happened. Now you need to explain it to six stakeholders, find out what actually went wrong, make sure it doesn't happen again, and do all of this without starting a war inside your own team. That's the job of an AI incident review, and it's one of the messiest things people try to use AI prompts for.

AI can help. It can also turn a real learning opportunity into a polished document that explains nothing, reassigns blame to "process failures," and makes everyone feel like they did a great retrospective when they actually just laundered the problem.

This guide gives you 10 copy-paste AI incident review prompts, a reusable formula, and the warnings you need to not make things worse.

Why AI incident review prompts are actually useful

An incident review has a few distinct jobs: build an accurate timeline, separate what you know from what you're guessing, figure out what actually caused the problem, assign clear follow-up actions, and communicate clearly to different audiences. Each of those is a different document task, and AI is genuinely good at document tasks.

What AI is not good at is deciding which detail matters, knowing when someone's explanation is self-serving, or telling you that the clean narrative in your notes is hiding a real risk. That part is yours. Rule #7 in Don't Replace Me calls it the taste moat: knowing which lesson is real and which one is convenient. AI doesn't have taste. You do.

Use the prompts below to handle the structure and drafting. Keep the judgment.

The reusable AI incident review prompt formula

Before the 10 prompts, here's the formula behind all of them. Every good incident review prompt gives AI four things:

  1. Your role and context. What kind of incident was this? What's your role in the review?
  2. The raw material. Notes, timelines, Slack threads, meeting summaries. The more specific, the better.
  3. The output format. What do you actually need: a table, a narrative, a summary, a draft?
  4. The constraints. What should it avoid: assigning blame, speculating beyond the facts, inventing causes?

Bad input gives you confident nonsense. That isn't just a data science cliche, it's the entire story of bad AI incident reviews. If you want a plain-language breakdown of what AI is actually good at versus where it confidently makes things up, what AI can and can't do covers that clearly.

A critical safety note before you paste anything

Do not paste the following into unapproved AI tools:

If your incident involves any of these, stop and involve the right people first. Legal, security, HR, finance, customer leadership, and incident response teams exist for exactly this situation. AI prompts are for organizing information you're already allowed to share, not for bypassing the conversations that protect you and your company.

This came from a book.

Don't Replace Me

200+ pages. 24 chapters. The honest version of what AI means for your career, written by someone who actually builds this stuff.

Get the Book →

10 AI incident review prompts you can use today

Prompt 1: Build an incident timeline

You are helping me structure an incident review. I'm going to paste my raw notes from [incident name/date]. 

Your job: extract a chronological timeline of events. For each entry, include the timestamp (if available), what happened, who was involved, and the source of the information (for example, "noted by [role], Slack message, monitoring alert"). 

Mark any entry where the timing is unclear or the source is a single person's recollection. Do not infer causes or assign responsibility. Only organize what's explicitly stated in the notes.

My notes: [paste your notes here]

Prompt 2: Separate facts from assumptions

Review the incident notes I'm pasting below. Sort every statement into one of three categories:
- CONFIRMED FACT: directly observed, logged, or documented
- REASONABLE ASSUMPTION: plausible given the evidence but not confirmed
- SPECULATION: not supported by evidence in these notes

For each assumption or speculation, flag what additional information would confirm or rule it out.

Notes: [paste your notes here]

Prompt 3: Write a neutral incident summary

Write a neutral, factual summary of the following incident for an internal review document. 

Tone: clear and professional, no blame assigned to individuals. Describe what happened, when, what was affected, what the impact was, and what initial response steps were taken. 

Do not speculate about root cause in this summary. Do not use passive voice to obscure who made decisions. If a decision was made, say a decision was made and by which team (not individual names unless relevant and confirmed).

Source material: [paste your notes here]

Prompt 4: Identify contributing factors

Based on the incident summary below, help me identify contributing factors. These are conditions that made the incident possible or worse, not a single root cause.

For each factor, note:
- What category it falls into (process, tooling, communication, environment, knowledge gap, etc.)
- Whether this factor is confirmed by evidence or inferred
- What evidence supports it

Avoid framing this as "who caused what." Frame it as "what conditions existed." Flag any factor that requires more investigation before it can be confirmed.

Summary: [paste your clean summary here]

Prompt 5: Turn messy notes into a review brief

I have messy notes from an incident that happened on [date]. I need to turn them into a structured review brief for [audience: your team / leadership / cross-functional group].

The brief should include:
- Incident title and date
- Severity (I'll fill this in)
- What happened (2-3 sentences)
- Who was affected and how
- Timeline (condensed, major events only)
- Contributing factors (preliminary)
- What was done to resolve it
- Open questions
- Proposed next steps

Flag anything that needs to be verified before the brief goes out. Do not invent details I haven't provided.

My notes: [paste here]

For help structuring what goes into a brief, the AI status report prompts guide has a useful set of templates for turning incident updates into clear stakeholder communication.

Prompt 6: Draft follow-up actions

Based on the incident review below, help me draft a follow-up action table.

For each action item, include:
- The specific action (concrete, not vague)
- The team or role responsible (not vague ownership like "everyone" or "the team")
- The deadline
- How we'll know it's done (success criteria)
- Whether this is a short-term fix or a longer-term systemic change

If an action is vague in the source material, rewrite it as a specific task or flag it as needing more definition before it can be owned.

Source material: [paste your notes or initial action list here]

Prompt 7: Prepare a customer-safe update

I need to write an external update for affected customers about an incident that occurred on [date]. 

Write a clear, honest, professional message that:
- Acknowledges what happened (without technical jargon)
- States the impact on customers
- Explains what was done to resolve it
- Describes what we're doing to prevent recurrence
- Avoids: blaming individuals, overpromising, speculation about causes, and language that minimizes the impact

Keep it under 200 words. Flag any claim that I need to verify before this goes out.

Incident summary: [paste your neutral summary here]

For drafting difficult customer communications around incidents, the AI client communication prompts guide covers how to write the harder messages clearly.

Prompt 8: Create an executive summary

Write a short executive summary of the following incident for senior leadership. 

Length: under 150 words. 

Include:
- What happened and when
- Business or customer impact (quantified if the data is in my notes; do not estimate)
- Root causes (preliminary, flagged as unconfirmed if not yet verified)
- What was done
- Key decisions made and by whom (team level)
- What needs a decision or resource from leadership

Do not include speculative causes. Do not soften language about impact. Write for people who don't have context on the technical details.

Source material: [paste brief or notes here]

Prompt 9: Check whether action items are real

Review the following list of action items from our incident review. For each item, evaluate:

- Is this action specific enough to be owned and completed, or is it a vague intention?
- Does it have a clear owner?
- Does it have a deadline?
- Is it addressing a root cause or contributing factor, or is it theater (an action that sounds useful but won't change the conditions that caused the incident)?

Flag any item that needs to be rewritten or challenged before the review closes.

Action items: [paste your current action list here]

This is the prompt most teams skip. It's also the most valuable one, because bad incident reviews close with action items that are theatrical. "Improve documentation" assigned to no one with no deadline is not an action item. It's a way to end the meeting.

If you want to track follow-through systematically, the AI risk assessment prompts guide covers how to map what happens if the actions don't get done.

Prompt 10: Plan a 30-day follow-through review

I want to schedule a 30-day follow-through check on the action items from an incident that occurred on [date]. 

Draft a short agenda for a 30-minute follow-through review meeting. Include:
- A check-in on each action item (complete, in progress, blocked, not started)
- A review of any recurrences or related issues since the incident
- An evaluation of whether the contributing factors have changed
- Time to confirm or close open questions from the original review
- A decision point: is this incident fully closed, or does it need to stay open?

Also draft a brief reminder message I can send to action owners two weeks before the review.

Action items from original review: [paste here]
Original incident date: [date]

What AI incident review prompts can't do

Here's the short version: AI can organize your information. It can't tell you whether the information is complete, honest, or the right frame for what actually happened.

It will confidently produce a contributing factors list from vague notes. That list will feel authoritative. It probably won't be. Speed is not the same as truth, and the gap between the two is where bad incident reviews live.

The actual work of an incident review is human. Someone needs to decide whether the action items are real or ceremonial. Someone needs to push back when the narrative is too clean. Someone needs to say "we don't actually know that yet" when the document implies certainty. That's not AI's job. It's yours.

For escalation decisions, especially when an incident involves legal risk, security exposure, customer safety, or significant business impact, the AI escalation plan prompts guide covers how to think about who needs to know and when.

If the broader question of what AI is actually good at and what it quietly gets wrong keeps coming up in your work, what AI can and can't do is a useful reference for keeping the right level of skepticism without becoming paralyzed by it.

Frequently asked questions

Can I use ChatGPT or Claude to write an incident review?

Yes, with the right input and appropriate skepticism. AI can organize timelines, draft summaries, and structure action items. It can't verify facts, assess blame fairly, or replace the human judgment needed to determine whether a review is honest. Always verify AI output against source documentation before sharing it.

What should I never paste into AI when doing an incident review?

Never paste customer PII, employee records, security credentials, legal documents, financial forecasts, medical or safety data, confidential client information, or anything from a board or regulatory process into unapproved AI tools. When in doubt, involve legal, security, HR, or your incident response team before using AI.

How do I stop an incident review from becoming a blame exercise?

Separate facts from assumptions early (Prompt 2 above), use contributing factors instead of root cause framing (Prompt 4), and write summaries in neutral language focused on conditions rather than individuals (Prompt 3). If the review is legally sensitive, involve HR or legal before the meeting, not after.

What's the difference between an incident review and a retrospective?

An incident review focuses on a specific failure or disruption: what happened, the impact, the causes, and the actions. A retrospective is broader, covering what worked and what didn't across a sprint or project. For retrospective prompts, the AI retrospective prompts guide covers that format specifically.

How do I make sure action items from an incident review actually get done?

Use Prompt 9 to check that action items are specific, owned, and deadline-bound before the review closes. Schedule the 30-day follow-through using Prompt 10. The most common failure mode is closing a review with action items that are vague, unowned, or not connected to an actual cause.

Stop and get the right people involved before using any AI tool. HR conversations, employee misconduct, legal disputes, and regulatory incidents require proper handling that AI prompts cannot provide. Use these prompts only for the operational and communication parts of an incident review once the sensitive elements have been appropriately contained.

The whole point of an incident review is to learn something real and do something about it. AI helps with the drafting. The learning is still yours. If you want a sharper map for staying useful when everything is moving fast, Don't Replace Me is the field guide for exactly that, including why the human who can tell real lessons from polished ones is the one who keeps their seat.