Blameless Postmortem Writer

Turn incident notes into a learning document.

Added October 15, 2026. Written with AI assistance and checked for clarity and placeholders; not reviewed by a lawyer, accountant, clinician or other professional. How these prompts are made

The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.

Write a blameless postmortem from my notes. Incident summary: [SUMMARY]. Timeline with times and events: [TIMELINE]. Impact (users, duration, revenue if known): [IMPACT]. What we did to fix it: [FIX]. What we think caused it: [SUSPECTED_CAUSES].

Produce: a one-paragraph summary; a clean timeline table; impact in numbers; contributing factors described as system and process conditions, not people; what went well; what went poorly; where we got lucky; and action items. For each action item give an owner role, a due date placeholder, a priority, and how we will know it worked. Avoid the phrases human error and root cause as a single cause; use contributing factors instead. Challenge any statement in my notes that assigns blame to an individual and rewrite it in neutral terms. List questions I should answer before finalising because the notes are incomplete.

Finish with a short review section that checks the draft against a quality list: is there a timeline with times, are contributing factors systemic, do action items have owners and due dates, are there prevention and detection actions, and is the language free of blame. Return the review result as a table with pass or needs work for each item.

Add a final section that converts the action items into a prioritised plan. Classify each action as prevent, detect, mitigate or process, estimate effort as small, medium or large, and mark the one action that would have reduced customer impact the most. Check the proposed actions against two failure patterns: actions that only say be more careful, which should be rewritten as a control, and actions that have no owner. Provide a ninety-second verbal summary for leadership, a three-sentence customer-safe version of the cause, and a template for the follow-up review thirty days later that asks whether each action was completed and whether it worked. Mark every statement of cause that rests only on my notes as unconfirmed.

Fill in before use

Optional: type your details and the prompt above updates. Nothing is saved or sent.

Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.

Summary: On 3 March, checkout failed for 41 minutes, affecting about 6% of orders.
Timeline: 14:02 deploy; 14:09 error rate rises; 14:20 page; 14:43 rollback; 14:50 recovery.
Contributing factors: a config change was not covered by staging checks; the alert threshold was too high to page early; the runbook lacked a rollback command.
Went well: quick rollback decision.
Where we got lucky: low traffic hour.
Actions: add config validation in CI (owner: platform, priority high); lower alert threshold (on-call lead); add rollback step to runbook (service owner).
Rewritten line: "The engineer misconfigured X" becomes "The change process allowed an unvalidated value."

• incident
• structured-brief