Incident postmortem from timeline and alerts

Use this workflow after service restoration, while the alert history and incident chat are still available. You will produce a review-ready postmortem with a verified timeline, stated impact, contributing factors, assigned actions and a clear handover.

This is for the incident manager or on-call engineer closing a production incident. It does not replace the technical review. It turns scattered evidence into a first draft that the people involved can check and amend.

1. Create the incident evidence pack

Make one working document named INC-<id>-evidence. Do not paste an unstructured chat export and expect a reliable account. Put every item in a dated section, using one time zone throughout, normally UTC.

Include these fields:

• Incident ID, service name, severity, incident commander and scribe.
• Start time, detection time, mitigation time, recovery time and end time. Leave a field as unknown if you cannot support it.
• Customer impact: affected feature, user group or tenant group, observed symptom, and the source that supports it.
• Alert history: alert name, first firing time, later state changes, dashboard values and alert links or identifiers.
• Timeline notes: relevant chat updates, paging events, deploys, configuration changes, rollbacks, escalations and decisions.
• Technical evidence: logs, traces, error messages, graphs and change references. Summarise long items in your own words, but preserve the original identifier.
• People and teams: use roles where names are not needed, such as on-call engineer or database team.

Remove secrets, access tokens, personal data, customer content and private chat that does not establish an incident fact. Keep the original material in your approved incident system. Use the working document only for the minimum evidence needed to draft the review.

2. Normalise the timeline before prompting

Put the events into a simple table. One row should describe one event. This prevents a later chat summary from being mistaken for the time the event occurred.

UTC time	Event	Evidence source	Confidence
10:02	Error-rate alert fired	alert history	confirmed
10:07	On-call acknowledged page	paging record	confirmed
10:18	Traffic was shifted	incident chat and change record	confirmed
10:31	Error rate returned to baseline	dashboard	confirmed

Use confirmed, reported, or unknown in the Confidence column. If two sources disagree, retain both values and add a row that says timestamp conflict. Do not silently choose the more convenient one.

Identify the incident boundary now. For example, distinguish the first customer error from the first alert, and distinguish mitigation from full recovery. This makes the eventual impact duration defensible.

3. Ask for a constrained first draft

Start a new conversation and paste the evidence pack. If the material is too large for one input, split it by section and label each part, for example Evidence 1 of 3: alert history. Ask for no draft until all parts are supplied. Input handling can vary, so check the current guidance in the xAI documentation overview if you need to work with long material or attachments.

Then use this prompt:

Create a blameless production incident postmortem from the evidence below.

Use only stated evidence. Do not infer a root cause, affected customer count, duration, owner or timestamp. Mark missing information as [unknown] and hypotheses as [unconfirmed].

Use these headings exactly:
1. Summary
2. Customer and service impact
3. Detection
4. Timeline (UTC)
5. What happened
6. Contributing factors
7. What went well
8. What made response harder
9. Corrective actions
10. Open questions

For each corrective action, provide: action, intended risk reduction, proposed owner, due date [unknown if absent], and evidence or reasoning. Make actions specific and testable. Do not assign blame to an individual.

After the postmortem, add an Evidence gaps section listing every material claim that needs human confirmation.

Evidence:
[paste the evidence pack]

Do not ask for a “root cause” if the investigation is incomplete. Ask instead for contributing factors. This keeps the document accurate when several conditions, decisions and system behaviours combined.

4. Check the draft against the evidence

Read the draft beside the INC-<id>-evidence document. Check the high-consequence fields first:

If you see this	Check this	Do this if wrong
An impact duration	Start and recovery evidence	Correct the times or mark it unknown
A causal statement	Logs, traces or a confirmed technical finding	Change it to a hypothesis or contributing factor
A named owner	Team agreement or incident record	Replace with proposed owner and seek confirmation
A completed action	Change record and verification evidence	State the actual status, not the intended status

Also check whether the draft uses loaded language such as “careless”, “failed to notice”, or “should have known”. Replace it with observable system conditions and decisions. For example, write “the alert threshold did not page until error rate exceeded the configured value”, not “the team ignored early warnings”.

5. Turn actions into an owned follow-up list

Copy the corrective actions into your team’s tracking system only after an owner accepts each one. Each action needs a completion test, not just a task name.

Weak action: Improve monitoring.

Useful action: Add an alert for sustained checkout request failures; page the payments on-call after the agreed threshold; verify with a controlled test; proposed owner: payments team.

Separate work into:

• Immediate containment: changes already made during the incident.
• Prevention: changes intended to reduce recurrence.
• Detection: alerts, dashboards and runbook changes that shorten discovery.
• Response: access, escalation or coordination changes that shorten mitigation.

Set the postmortem status to draft until the incident commander, relevant service owner and accepted action owners have reviewed it. Record unresolved questions explicitly rather than holding publication for every minor detail.

6. Hand over the finished record

Publish the checked postmortem in the incident record. Link the alert history, change records, action tickets and the final timeline. Tell the next on-call shift three things: any residual risk, the next decision point, and which action or investigation is still unowned.

If the draft is vague, contradictory or confident about facts you did not provide, do not edit around the problem. Return to the evidence pack, add the missing source or mark the gap as unknown, then generate only the affected sections again. If the tool keeps mixing sources or losing timeline order, reduce the input to the normalised event table and ask for the timeline first. Build the narrative only after that timeline is correct.