Incident postmortem template
Answer a few questions about the incident and copy a blameless postmortem in Markdown, ready for your wiki, a GitHub issue or Notion. Leave a field empty and its section stays as a prompt to fill in later. Nothing you type leaves your browser.
# Postmortem: _Incident title_
| | |
| --- | --- |
| Severity | _SEV level_ |
| Started | _YYYY-MM-DD HH:MM UTC_ |
| Resolved | _YYYY-MM-DD HH:MM UTC_ |
| Duration | _Resolved minus started_ |
| Status | Draft — blameless review |
## Summary
_What happened, in two sentences, for someone who was not there._
## Impact
_Who was affected, how many, for how long, and what they could not do._
## Timeline (UTC)
- _HH:MM First sign of the problem (alert, customer report)_
- _HH:MM Incident declared_
- _HH:MM Mitigation applied_
- _HH:MM Resolved_
## Root cause
_The underlying cause, not the trigger. Ask why until the answer is a system or process, not a person._
## Resolution
_What stopped the impact, and what restored normal service._
## What went well
- _Detection, communication or tooling that helped_
## What went badly
- _Gaps that slowed detection, diagnosis or recovery_
## Action items
| Action | Owner | Due |
| --- | --- | --- |
| _Prevent a repeat_ | _owner_ | _date_ |
| _Detect it sooner_ | _owner_ | _date_ |
Write it while the facts are fresh
The timeline is the part that fades first. Uptimely records each incident’s state changes, notes and the monitors that triggered it, and its incidents have a postmortem field, so the timeline is already written when you sit down to review. The incident management glossary defines the terms.
Catch the next one sooner
Most postmortems list “detect it sooner” as an action. Uptimely checks your sites and APIs every minute and pages the on-call engineer when they fail.
What should an incident postmortem include?
A short summary, the impact on users, a timeline in UTC, the root cause, how the incident was resolved, what went well and badly, and action items with an owner and a due date. The template above has a section for each.
What does blameless mean in a postmortem?
The review looks for the system and process causes that let a mistake turn into an outage, rather than for a person to blame. People describe what they saw and did honestly when they are not afraid of the outcome, which is the only way to find the real causes.
When should a postmortem be written?
Within a few days of the incident, while the timeline is still fresh, for any incident that affected customers or needed an emergency response. Short incidents still deserve a short postmortem when they reveal something new.
Is what I type stored anywhere?
No. The document is assembled in your browser as you type. Nothing is sent to Uptimely or saved.