You do not need an incident command team or a two-hour meeting to learn from a production failure. A concise written review can preserve what users experienced, reconstruct the timeline and identify one system change that lowers the chance or impact of recurrence. The purpose is not to prove you should have known better; it is to improve the environment in which the next decision will be made.
| Review section | Prompt | Useful evidence |
|---|---|---|
| Summary | What failed and for whom? | Start/end, duration, users and business effect |
| Detection | How did you learn about it? | Alert, synthetic check, customer report or manual discovery |
| Timeline | What did you observe and do? | Timestamped deploys, logs, changes and mitigations |
| Contributing conditions | Why was failure possible or hard to detect? | Missing test, unsafe default, dependency or unclear runbook |
| Follow-up | What change prevents recurrence or limits impact? | Small action with owner, date and completion evidence |
Keep facts and hypotheses separate. “The import completed with 0 rows after the provider changed a field” is an observation; “I forgot to test it” is an incomplete explanation. Ask what made the change invisible, why the importer treated it as success and which check could have caught it before customer data was affected. Avoid a single “root cause” if several conditions combined.
Blamelessness is useful for solo work too. Shame discourages honest notes and encourages hiding near misses. Assume you made the best decision available with the information and tools at the time. Then improve the system: add a contract check, safer default, rollback switch, alert, backup verification or clearer runbook. The goal is not self-forgiveness in place of accountability; it is accountability aimed at the conditions you can change.
“Rewrite the integration” is not an action plan. Prefer a specific change such as “reject an unknown schema version and alert before writing any records.” Give it a realistic due date and define proof: a test, dashboard signal, restore exercise or runbook check. One completed high-leverage action is better than a list that stays open forever.
Write a review after user-visible outage, data loss, a rollback, repeated manual recovery, a missed alert or any event that taught you something material. Skip the ceremony for harmless local mistakes; keep a short note if the pattern may recur. A monthly glance at incidents and near misses can reveal that separate failures share one weak boundary.
Summary: … Impact: … Detection: … Timeline: … Contributing conditions: … What worked: … Actions: owner / due date / evidence. Store it beside the service runbook, redact customer identifiers and revisit actions until verified complete.
A solo postmortem can be ten focused minutes and a page of notes. Preserve evidence, describe impact, explain system conditions without blame and commit to one verifiable improvement. The review has value only when its lesson changes a test, guardrail, alert or recovery procedure.