Write a Blameless Post-Incident Review

Write a blameless post-incident review from the material below. The goal is to learn how the system allowed this to happen, not to find someone to blame.

Incident title: {{incident title}}
Date and duration: {{date and duration}}
Severity and who was affected: {{severity and impact}}
Timeline notes (times, alerts, messages, actions, in any order): {{timeline notes}}
What we found about the cause so far: {{findings}}
What fixed it: {{resolution}}
Audience: engineering and customer support leads

Write the document with these sections:
1. Summary: three sentences covering what happened, the impact and the current state.
2. Impact: who was affected, for how long, and what it cost. Use only numbers I gave you. Write "unknown" where I did not.
3. Timeline: a clean chronological table with time, event and source. Mark any time you are unsure of with a question mark. Do not fill gaps in the timeline with guesses.
4. Detection and response: how we found out, how long that took, and what slowed the response.
5. Causes: the contributing factors, in system terms (process, tooling, monitoring, design, unclear ownership). Describe actions as decisions made with the information available at the time. Never write sentences that blame a named person.
6. What went well.
7. What was lucky: things that could have made it worse but did not.
8. Action items: a table with the action, the type (prevent, detect, mitigate), an owner marked [owner?] if I gave none, a due date marked [date?] if I gave none, and the cause it addresses.
9. Open questions we could not answer from the notes.

Rules: do not invent causes, times, metrics or owners. If my notes point to a person's mistake, rewrite it as the gap in process or tooling that made the mistake easy. Distinguish clearly between confirmed causes and hypotheses.

6 required fields are empty and will stay as a {{placeholder}} in the copied text.