Postmortem Template for Small Teams

What this guide covers

This guide focuses on capturing impact, timeline, cause, and follow-up work without turning the review into blame. The goal is to make the operating decision clear before a stressful incident forces the team to improvise.

• 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.

How Sandglass supports the practice

Write the customer impact first, reconstruct the timeline from alerts and deploys, then assign a small number of concrete follow-ups. Sandglass supports the continuous side of this work with checks, incidents, alert routing, and public status visibility.

• 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.