Incident postmortem prompt

Paste this into a chat window and replace each {{variable}}, or open it in the prompt builder to fill them in a form. Sections are marked with XML tags, which every major model reads well.

You write blameless incident postmortems. You focus on systems and decisions, never on individuals.

<context>
Timeline, alerts and chat logs from the incident:
<incident_log>
{{incident_log}}
</incident_log>

Impact data:
<impact>
{{impact}}
</impact>
</context>

<constraints>
- Blameless: describe actions and the information people had at the time, not who made a mistake. Refer to roles (on-call engineer, release manager), not names.
- Separate the trigger, the root cause and the contributing factors. Don’t stop at the first cause.
- Only state facts the logs or impact data support. Mark anything inferred as “likely”, and list open questions at the end.
- Each action item must be specific and checkable, such as “alert when queue depth exceeds 10,000 for 5 minutes”, not “improve monitoring”.
- Use UTC times from the logs.
</constraints>

<output_format>
Markdown:
## Summary (three sentences)
## Impact
## Timeline (UTC)
## Root cause and contributing factors
## What went well
## Action items (table: action, type: prevent, detect or mitigate)
## Open questions
</output_format>

<task>
Write the postmortem for this incident.
</task>

You write blameless incident postmortems. You focus on systems and decisions, never on individuals.

<constraints>
- Blameless: describe actions and the information people had at the time, not who made a mistake. Refer to roles (on-call engineer, release manager), not names.
- Separate the trigger, the root cause and the contributing factors. Don’t stop at the first cause.
- Only state facts the logs or impact data support. Mark anything inferred as “likely”, and list open questions at the end.
- Each action item must be specific and checkable, such as “alert when queue depth exceeds 10,000 for 5 minutes”, not “improve monitoring”.
- Use UTC times from the logs.
</constraints>

<output_format>
Markdown:
## Summary (three sentences)
## Impact
## Timeline (UTC)
## Root cause and contributing factors
## What went well
## Action items (table: action, type: prevent, detect or mitigate)
## Open questions
</output_format>

<context>
Timeline, alerts and chat logs from the incident:
<incident_log>
{{incident_log}}
</incident_log>

Impact data:
<impact>
{{impact}}
</impact>
</context>

<task>
Write the postmortem for this incident.
</task>

{{incident_log}}

The raw material: alert times, the incident channel export, deploy log entries, relevant metrics. Remove secrets and customer personal data first.

{{impact}}

Who was affected and how much: error rates, duration, number of customers, money, SLA breaches. Use real numbers where you have them.

{{incident_log}}

14:02 UTC deploy 2026.10.03-2 to production (adds index on orders.created_at)
14:03 alert: API p95 latency > 2s
14:05 on-call: "orders table locked? migration still running"
14:21 migration finished, latency recovers
14:30 release manager: "index was created without CONCURRENTLY"

{{impact}}

Checkout API errors for 18 minutes; about 3,100 failed checkout attempts; no data lost.

What to look for. The trigger is the deploy; a good draft identifies the root cause as an index created without CONCURRENTLY, which locked the table, and the contributing factor as nothing in review or CI catching locking migrations. A strong action item is a migration linter rule, typed as “prevent”.

You write blameless incident postmortems. You focus on systems and decisions, never on individuals.

<context>
Timeline, alerts and chat logs from the incident:
<incident_log>
14:02 UTC deploy 2026.10.03-2 to production (adds index on orders.created_at)
14:03 alert: API p95 latency > 2s
14:05 on-call: "orders table locked? migration still running"
14:21 migration finished, latency recovers
14:30 release manager: "index was created without CONCURRENTLY"
</incident_log>

Impact data:
<impact>
Checkout API errors for 18 minutes; about 3,100 failed checkout attempts; no data lost.
</impact>
</context>

<constraints>
- Blameless: describe actions and the information people had at the time, not who made a mistake. Refer to roles (on-call engineer, release manager), not names.
- Separate the trigger, the root cause and the contributing factors. Don’t stop at the first cause.
- Only state facts the logs or impact data support. Mark anything inferred as “likely”, and list open questions at the end.
- Each action item must be specific and checkable, such as “alert when queue depth exceeds 10,000 for 5 minutes”, not “improve monitoring”.
- Use UTC times from the logs.
</constraints>

<output_format>
Markdown:
## Summary (three sentences)
## Impact
## Timeline (UTC)
## Root cause and contributing factors
## What went well
## Action items (table: action, type: prevent, detect or mitigate)
## Open questions
</output_format>

<task>
Write the postmortem for this incident.
</task>

• Claude

  For long logs, Anthropic suggests asking Claude to extract the relevant quotes before writing. A first step of “list the log lines that establish each timeline entry” makes every timeline row traceable.

• Gemini

  Gemini’s large context window fits long channel exports. Google’s guide suggests putting the material first and the instructions at the end, which is how the builder lays this template out.

• All models

  Strip personal data and secrets from logs before pasting them into any model, and check your organisation’s policy on sending incident data to an external API.

• Summarise logsTurn a long log into a timeline, the distinct errors with counts, and the likely first failure.
• Debug from a stack traceRank likely root causes from an error and stack trace, say what to check first, and suggest the smallest fix.
• Architecture decision recordTurn design discussion notes into a short ADR: context, options, decision and consequences.

Edited the template? Compare your version with this one in the prompt diff, and count it for your model with the token counter. Browse all 29 prompt templates.