The SaaS Founder's Guide to Incident Post-Mortems

The SaaS Founder's Guide to Incident Post-Mortems

Key Facts

• Direct answer: The direct answer is that a post-mortem is a document written after an incident that describes what happened, why it happened, what was done to fix it, and what will be done to prevent it from happening again.

• The Post-Mortem Template: Write the post-mortem while the incident is fresh in your mind.

• The Post-Mortem Process: Write the post-mortem while the incident is fresh in your mind.

Every incident is a learning opportunity. Without a post-mortem, you fix the immediate issue and move on, but the root cause remains, and the incident repeats. With a post-mortem, you identify the root cause, implement preventive measures, and reduce the likelihood of recurrence. This article is the founder's guide to writing incident post-mortems that prevent recurrence and build trust.

The direct answer is that a post-mortem is a document written after an incident that describes what happened, why it happened, what was done to fix it, and what will be done to prevent it from happening again. The key principle is blamelessness: post-mortems focus on the system, not the person. For more on incident response, see our article on how to handle your first SaaS deployment incident.

The Post-Mortem Template

## Incident: [Title]

**Date:** [Date]
**Duration:** [Duration]
**Impact:** [Number of users affected, features affected, revenue impact]
**Severity:** [SEV1 (critical), SEV2 (major), SEV3 (minor)]

### Summary
[1-2 sentence summary of what happened]

### Timeline
- [Time]: Issue detected (how?)
- [Time]: Investigation started
- [Time]: Root cause identified
- [Time]: Fix applied
- [Time]: Issue resolved
- [Time]: Post-mortem published

### Root Cause
[Technical description of what caused the incident. Be specific.]

### Resolution
[What was done to fix the immediate issue]

### Impact
[Who was affected, how many users, what features were unavailable, any data loss]

### What Went Well
[What worked during the incident response — e.g., monitoring detected it quickly, rollback worked]

### What Went Wrong
[What did not work — e.g., alert was delayed, rollback was slow, communication was poor]

### Action Items
- [ ] [Action item 1] — [Owner] — [Due date]
- [ ] [Action item 2] — [Owner] — [Due date]
- [ ] [Action item 3] — [Owner] — [Due date]

### Lessons Learned
[What was learned from the incident]

The Post-Mortem Process

Step 1: Write the post-mortem within 48 hours

Write the post-mortem while the incident is fresh in your mind. After 48 hours, details fade, and the post-mortem becomes less accurate.

Step 2: Be blameless

Post-mortems focus on the system, not the person. Instead of "John deployed the broken code," write "the deployment process did not catch the broken code." The goal is to improve the system, not to assign blame.

Step 3: Identify the root cause

Use the "5 Whys" technique: ask "why?" five times to drill down to the root cause.

• Why did the app go down? Because the database connection pool was exhausted.
• Why was the pool exhausted? Because a new query was opening connections without closing them.
• Why was the query opening connections without closing them? Because the ORM was misconfigured.
• Why was the ORM misconfigured? Because the configuration was not reviewed before deployment.
• Why was the configuration not reviewed? Because there is no code review process for configuration changes.

Root cause: no code review process for configuration changes. Action item: implement code review for configuration changes.

Step 4: Create action items

Each action item should be specific, assigned, and dated:

• "Add a connection pool monitor" — Founder — October 15
• "Implement code review for configuration changes" — Founder — October 22
• "Add a test for connection pool behavior" — Founder — October 29

Step 5: Publish the post-mortem

Publish the post-mortem on your status page (or blog) for transparency. Customers appreciate honesty, and it builds trust.

For more on status pages, see our article on the SaaS founder's guide to status pages and customer communication.

Step 6: Follow up on action items

Review the action items in your weekly team meeting. Track them until they are complete. An action item without follow-up is just a wish.

Common Pitfalls and Troubleshooting

The first pitfall is not writing a post-mortem. Many founders fix the issue and move on, which means the root cause remains, and the incident repeats. The fix is to write a post-mortem for every incident (even minor ones).

The second pitfall is blaming individuals. If the post-mortem blames a person, the person becomes defensive, and the root cause (a system failure) is not addressed. The fix is to focus on the system, not the person.

The third pitfall is not identifying the root cause. If the post-mortem stops at the surface cause (e.g., "the database was down"), the root cause (e.g., "no connection pool monitor") is not addressed. The fix is to use the 5 Whys technique.

The fourth pitfall is not creating action items. Without action items, the post-mortem is just a document, not a change. The fix is to create specific, assigned, dated action items.

The fifth pitfall is not following up on action items. If action items are not tracked, they are forgotten. The fix is to review action items in weekly meetings until they are complete.

Conclusion: Learn from Every Incident

Every incident is a learning opportunity. By writing a blameless post-mortem within 48 hours, identifying the root cause (5 Whys), creating specific action items, and following up, you turn incidents into improvements that prevent recurrence. Post-mortems are not about assigning blame — they are about improving the system.

Ready to write your first post-mortem? Use the template above for your next incident, and publish it on your status page. For more, see how to handle your first SaaS deployment incident and the SaaS founder's guide to status pages. Explore our free developer tools to speed up your workflow.