Hyperping supports two kinds of post-mortem. The internal one is written on the incident itself, under Incident Management, and stays in the dashboard for your team. The public one is attached to a status page incident once it's resolved and appears at the top of it, above the updates posted during the outage, so customers asking "what happened yesterday?" get one link.
Post-mortem structure
- A summary in two or three sentences: what broke, for whom, and for how long.
- The impact, with numbers: duration, share of users or requests affected, data lost if any.
- A timeline in UTC, from the first sign of trouble to full recovery, including when it was detected and acknowledged.
- The root cause and the contributing factors. There is usually more than one.
- What went well and what didn't during the response.
- Action items, each with one owner and a due date.
The post-mortem template has these sections ready to fill in.
Writing a useful post-mortem
- Write it within a few days, while people remember the details and the logs are still there.
- Keep it blameless. Describe what people did and why it made sense with what they knew, and look for the system changes that would have prevented it. See blameless postmortem.
- Ask "why" until you reach something you can change. "The engineer ran the wrong command" isn't a root cause. "The command runs against production by default" is.
- Keep the action items few and real. Three done beat ten that sit in a backlog.
- Follow up. A post-mortem whose actions never ship will be rewritten for the same incident later.
Internal vs public post-mortems
The internal version is for engineers and includes everything: names in the timeline, internal systems, the commands that were run. The public version is for customers: what happened in plain words, how they were affected, and what you changed. Skip internal names and blame, apologize once, and be specific about the fix. A public post-mortem also helps with security reviews and enterprise buyers, who want to see how you handle incidents.
FAQ
When should you write a post-mortem?
For every SEV1 and SEV2 incident, for any data loss, and for any incident customers noticed. Also for near-misses that could have been serious.
Who writes the post-mortem?
Usually the incident lead or the on-call engineer who handled it, with input from everyone involved. The whole team reviews it together.
What is the difference between a post-mortem and a root cause analysis?
A root cause analysis is one section of the post-mortem. The post-mortem also covers the impact, the timeline, the response, and the follow-up actions.