Postmortem Template for Small Teams

What this guide covers

A postmortem turns an incident into something the team learns from instead of just survives. This guide gives you a lightweight, blameless template that captures what mattered — impact, timeline, cause, and follow-ups — and explains how to run the review so it actually changes the next incident rather than filing a document nobody reads.

• Reconstruct the timeline from alerts and deploys, not memory.
• Keep follow-ups few, concrete, and owned.
• Focus on the system that failed, not the person.

The template

Keep it to sections a small team can fill in within an hour of the incident:

• Summary — one paragraph: what happened and the customer impact.
• Impact — who was affected, for how long, and how severely.
• Timeline — key timestamps from detection to recovery, with what happened at each.
• Root cause — the technical and contributing causes, honestly.
• What went well / what did not — detection speed, response, communication.
• Follow-ups — a short list of concrete actions, each with an owner and a due date.

Running a blameless review

Blameless does not mean nobody is accountable — it means you assume everyone acted reasonably with the information they had, and you fix the system that let a reasonable action cause an outage. The productive question is "what made this failure possible and easy?" not "who pushed the button?" When people trust that reviews target systems rather than individuals, they surface the real causes instead of the defensible ones.

How Sandglass supports the practice

Reconstruct the timeline from real events: when the check failed, when the alert fired, when someone acknowledged it, and when it recovered. Sandglass records these timestamps, so the "detection" and "recovery" rows of your timeline come from data. Fill in the human actions — what you tried, what worked — around that spine.

• Back the practices here with HTTP, ping, TCP, content, SSL certificate, and heartbeat checks.
• Route incidents to email, Slack webhook channels, and generic webhooks so the right people respond fast.
• Use a public status page to keep customers informed while the team works the incident.

Common mistakes to avoid

A postmortem that lists vague lessons but no owner and due date will not change the next incident. "We should improve monitoring" is not a follow-up; "add an SSL expiry check on the payments domain — owner: Sam, due Friday" is. Equally, a review that turns into blame teaches people to hide problems, which is worse than the original incident.