Post-Mortem Template for Small Teams

A simple, practical incident post-mortem template for indie builders and small ops teams. No bureaucracy, just learning.

When something breaks at 2 AM and you're the only one awake, you don't need a 20-page incident report. You need a simple way to capture what happened, why it mattered, and what you'll do differently.

This is the post-mortem template I use. It's designed for teams of 1-5 people who want to learn from incidents without turning every outage into a paperwork exercise.

Why Post-Mortems Matter (Even for Solo Founders)

After an incident, your memory fades fast. Within 24 hours, you'll forget half the details. Within a week, you'll remember only the big picture.

A quick post-mortem captures:

• What actually happened (not what you think happened later)
• How long it took to detect and resolve
• What you could have done better
• Concrete actions to prevent recurrence

For solo builders, this becomes your personal runbook. For small teams, it's shared learning without the enterprise overhead.

The 15-Minute Post-Mortem Template

Here's the entire template. Copy it, adapt it, use it.

# Incident Post-Mortem: [Brief Description]

**Date:** [YYYY-MM-DD]
**Severity:** [Low/Medium/High/Critical]
**Duration:** [Detection to Resolution]
**Affected Users:** [Number or percentage]

## Timeline (UTC)
- [HH:MM] - Incident detected via [alert/source]
- [HH:MM] - First response by [who]
- [HH:MM] - Root cause identified
- [HH:MM] - Fix deployed
- [HH:MM] - Service fully restored

## Impact
- What broke?
- Who was affected?
- Any data loss or corruption?

## Root Cause
- What caused the incident?
- Why wasn't it caught earlier?

## What Went Well
- [Fast detection, good runbook, calm response, etc.]

## What Could Be Improved
- [Slow detection, missing alerts, unclear ownership, etc.]

## Action Items
| Action | Owner | Due |
|--------|-------|-----|
| [Specific task] | [Who] | [When] |

## Lessons Learned
- [One or two key takeaways for the team]

## Appendix
- Links to related alerts, logs, or documentation

That's it. No five-page documents. No blame games. Just the essentials.

How to Use This Template

Step 1: Fill It Out Within 24 Hours

Don't wait. The details fade quickly. Set a calendar reminder if you need to.

Step 2: Be Honest About What Went Wrong

This isn't about assigning blame—it's about improvement. If you missed an alert because you were asleep, say so. If the runbook was outdated, note it.

Step 3: Turn Lessons Into Action Items

Every post-mortem should produce at least one concrete action item:

• "Add alerting for X condition"
• "Update runbook with Y step"
• "Add integration test for Z scenario"

Step 4: Close the Loop

Check your action items within a week. Did you actually implement them? If not, why?

Common Anti-Patterns (Avoid These)

The Blame Game

"John deployed the bad code" is not a root cause. Ask why:

• Did John have adequate testing tools?
• Was there a code review process?
• Were there automated checks?

Focus on systems, not people.

The Post-Mortem That Never Happens

You fix the incident, promise to "write it up later," and never do. Then the same thing happens again.

Solution: Schedule the post-mortem immediately. 15 minutes now saves hours later.

The Document Nobody Reads

If your post-mortem is 10 pages, nobody will read it—not even you.

Keep it short. If you need more detail, link to external docs.

Action Items Without Owners

"Improve monitoring" is not an action item. "Add alert for >5% error rate on /api/checkout, assigned to Sarah, due Friday" is.

When to Do a Post-Mortem

Not every hiccup needs one. Here's my rule of thumb:

For a solo builder, even a "Low" incident might be worth documenting if it's a new failure mode you haven't seen before.

Building a Blameless Culture

For small teams, "blameless" doesn't mean "nobody's responsible." It means:

1. Focus on systems, not individuals
2. Assume good intent
3. Celebrate what went well, not just what went wrong
4. Turn mistakes into improvements, not punishments

If someone makes a mistake, the question isn't "who messed up?"—it's "what system allowed this mistake to happen, and how do we fix it?"

Summary

A good post-mortem:

• Takes 15 minutes, not hours
• Focuses on learning, not blame
• Produces concrete action items
• Gets reviewed and followed up

Use the template above, adapt it to your needs, and make incident learning a habit. Your future self will thank you.

Related Posts

• Incident Response Playbook for Small Teams
• Monitoring Checklist for SaaS Launch
• 5-Minute Uptime Monitoring Setup