Incident postmortem prompts help turn scattered notes into a record people can use during the next failure. The goal is not a polished story with an inevitable ending. It is an accurate account of impact, what the team knew at each point and which changes would improve the system. These prompts preserve uncertainty, separate recovery from prevention and connect follow-up actions to evidence.
Prepare an evidence bundle with consistent time
Collect relevant alerts, deployment events, support reports and responder notes. Use a consistent timezone and preserve original timestamps when converting them. Remove secrets and unnecessary customer details. State which impact measurements are confirmed and which are estimates. If two sources disagree, keep both in the bundle rather than silently choosing the one that fits the emerging narrative.
Google's postmortem guidance describes incident records, contributing causes and follow-up work in a blameless culture. This collection offers original drafting and review prompts. The agent should organize supplied evidence, not fabricate missing events or attribute motives to responders.
Build a timeline that shows changing knowledge
A timeline needs more than a list of messages. Include when the fault began, when people noticed it, when they formed a hypothesis and when service recovered. Those times may differ. Ask the agent to attach evidence to important entries and distinguish a mitigation being started from it taking effect.
Build an incident timeline from {{evidence_bundle}}.
Use {{timezone}} consistently. For each entry give time, event, evidence
and what responders knew then. Separate fault start, detection, mitigation
and recovery. Flag conflicting timestamps and gaps without filling them.
Keep customer identifiers out of the draft. List questions needed to
establish the impact window.
Explain the causal chain without hindsight
Ask what conditions allowed a change or failure to affect users, and which safeguards did or did not operate. A statement that someone made a mistake usually stops the investigation too early. Review the information and tools available at the time. If the exact trigger remains unknown, state the strongest supported conclusion and what evidence could change it.
Analyze contributing conditions for {{incident_summary}} using {{evidence}}.
Separate trigger, system conditions, detection gaps and recovery friction.
For each causal claim cite a supplied event or mark it as a hypothesis.
Explain why existing safeguards did not contain the impact.
Avoid assigning intent or blame. Identify unanswered questions and the
smallest investigation that could resolve each important one.
Convert lessons into verifiable actions
A follow-up such as improving monitoring is too vague to close reliably. Ask what signal will be added, who owns it and how a controlled test demonstrates it works. Not every action prevents recurrence; some reduce detection time or make recovery safer. Keeping those goals separate helps the team choose work honestly.
Turn {{postmortem_findings}} into a prioritized follow-up table.
For each action provide owner role, concrete change, prevention/detection/
mitigation goal, completion evidence and dependency. Tie it to a finding.
Separate immediate fixes from larger proposals. Do not invent deadlines
or named owners; mark them for assignment. Include a review date for
checking whether completed actions changed the relevant failure mode.
Review the record for accuracy and usefulness
Have a responder who was present check the chronology and impact. Ask another person whether the follow-up checks are understandable without the original chat log. Remove unsupported certainty from the summary and keep unresolved questions visible. A short accurate record is more useful than a detailed narrative that implies missing evidence exists.
Store the reusable postmortem prompts in Kipt, keeping incident-specific sensitive material in its approved system. Use the observability prompts when a follow-up requires a concrete detection or investigation design.