Jira postmortem template
A postmortem exists so the same incident does not happen twice. This template follows the postmortem structure Atlassian publishes in its Incident Management Handbook, with what to write in each section and a short example. Copy it into the incident's Jira work item, a Confluence page, or anywhere your team writes.
Write it blameless. Describe systems, conditions and decisions, not people's mistakes. "The deploy reduced the connection pool from 50 to 5" helps; "Sam broke checkout" teaches nobody anything and makes the next incident harder to report.
Before you start
Have these open: the incident's Jira work item and its history, the chat channel or thread where it was handled, the alert that fired, and the deploy log. Write within a few days of resolving. After a week, people reconstruct what they think happened.
The template
Executive summary
Two to four sentences a director can read: what broke, for whom, for how long, how bad, and why.
Between 14:05 and 14:47 UTC on 2 October, customers could not complete checkout: the payment step returned errors. A configuration change in the payments service reduced its connection pool below what normal traffic needs. SEV2, 42 minutes.
Leadup
The sequence of events that led to the incident, with times. Include the changes that made it possible, even ones made long before.
At 13:58, payments-api 4.12 was deployed, changing the card processor connection pool from 50 to 5.
Fault
What did not work as expected, technically. Include graphs or error rates if you have them.
Impact
Who was affected and how: internal and external users, how many, for how long, and how many support cases were raised.
Detection
When and how the team found out (an alert, a customer, a colleague) and how detection could have been faster. "Time to detect" belongs here.
Response
Who responded, what they did and when. Include delays and obstacles: a missing runbook, an access request, a pager that did not fire.
Recovery
How the impact was stopped (mitigation) and when the incident was considered over (resolution), and what would have shortened either.
Timeline
Every relevant event in UTC: first signal, alert, page, each decision, the fix, confirmation. This is the section people rebuild from memory and get wrong; it is the one most worth capturing as it happens.
Five whys
Ask why until you reach something you can change:
- Why did checkout fail? Payment requests timed out.
- Why did they time out? The connection pool was exhausted.
- Why was it exhausted? The deploy reduced it from 50 to 5.
- Why did the deploy change it? A copied config from a test environment.
- Why did review not catch it? Pool size is not part of the deploy checklist.
Blameless root cause
The final root cause in one or two sentences, and what needs to change to stop this class of incident.
Backlog check
Was there already work in the backlog that would have prevented this or reduced its impact? If so, why had it not been done?
Related incidents
Have similar incidents happened? What was tried then, and why did it happen again?
Lessons learned
What went well, what did not, and where you got lucky.
Follow-up tasks
Each corrective action as its own tracked work item, not a bullet point in a document, with an owner, a due date and what kind of action it is: prevent (stop it happening), detect (find it sooner), mitigate (make it hurt less) or process (change how you work). The postmortem is only finished when these are done.
| Action | Kind | Owner | Due |
|---|---|---|---|
| Add connection pool size to the deploy checklist | prevent | ||
| Alert on checkout error rate above 5% for 2 minutes | detect |
Copy the template
Paste this into a Jira work item description, a Confluence page or a doc, and replace each line:
Executive summary: what broke, for whom, how long, how bad, why
Leadup: events and changes that led to it, with times (UTC)
Fault: what did not work as expected
Impact: who was affected, how many, how long, support cases raised
Detection: when and how we found out; how to find out sooner
Response: who did what, when; delays and obstacles
Recovery: how impact stopped (mitigated) and when it ended (resolved)
Timeline: every relevant event in UTC
Five whys: why, why, why, why, why
Blameless root cause: the cause, and what changes to stop this class of incident
Backlog check: existing work that would have prevented it
Related incidents: has this happened before; what changed since
Lessons learned: what went well, what did not, where we got lucky
Follow-up tasks: action | kind (prevent/detect/mitigate/process) | owner | due
Running it in Jira
Without an app: create the postmortem as a Confluence page from Atlassian's incident postmortem blueprint, or paste the headings above into the incident work item's description, and raise each follow-up as a linked work item.
With Afterbrief, the template is built in: declare the incident on its work item, the timeline captures itself from Jira and Slack, the postmortem opens with these sections and their prompts, Draft with AI can write a first pass from the record, and follow-ups are Jira work items the app rolls up and chases until they are closed. See the setup guide.
Running the review meeting itself? See the post-incident review template.
Frequently asked questions
What is the difference between a postmortem and a post-incident review?
The postmortem is the written record: what happened, why, and what will change. The post-incident review is the meeting where the people involved check that record and agree the corrective actions. Most teams write the postmortem first and review it together.
How soon after an incident should the postmortem be written?
Within a few days of resolving it, while people remember. Many teams set a due date (five working days is common) and track it like any other work.
What makes a postmortem blameless?
It explains how the system and the circumstances allowed a reasonable person's action to cause harm, instead of naming who made a mistake. People report problems honestly only when they know a report will not be used against them.
Does Jira have a built-in postmortem template?
Jira Service Management includes post-incident reviews on its Premium plan. On other plans, teams use a Confluence page from Atlassian's incident postmortem blueprint, a template like this one, or an app such as Afterbrief.