What this template is for
Postmortems are the difference between a team that learns from incidents and one that has the same incident three times a year. The hard part isn’t writing the document - it’s making sure the action items actually ship.
This template structures both halves:
- Fields on the postmortem ticket - linked incident, customer impact, facilitator, the blameless write-up (timeline, contributing factors, what-went-well, what-went-poorly). Configured on the Jira create screen for the postmortem issue type.
- STM-created sub-tasks - schedule, draft timeline, identify factors, run discussion, convert action items to linked issues, publish, track to closure. The action-items step is the one that fails most often without help.
When to use it
Use this template for every SEV1, SEV2, and any SEV3 with novel contributing factors. SEV3s with already-known causes can use a lightweight write-up. SEV4 internal-only incidents usually don’t need a postmortem unless the team chooses to learn from them.
Don’t use this template for retrospectives on planned work (use the sprint-retrospective template) or for change-management reviews (use the change-request template).
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Postmortem: checkout 502s on 2026-05-19 (INC-1042) | Yes |
Linked Incident | INC-1042 | Yes |
Severity | SEV2 | Yes |
Customer Impact (custom) | ~12% of checkout sessions failing for 37 minutes | Yes |
Postmortem Date | 2026-05-26 (within 5 business days) | Yes |
Facilitator (custom) | @maria.lopez (NOT the on-call) | Yes |
Attendees (custom) | On-call, IC, comms, EM, PM | No |
Timeline (custom) | Bullet timeline; one line per significant event | Yes |
Contributing Factors (custom) | Multiple - not 'root cause' - what conditions enabled the incident? | Yes |
What Went Well (custom) | Detection within 4 mins; rollback worked first try | No |
What Went Poorly (custom) | Page didn't reach secondary on-call; status page lag | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Schedule postmortem meeting within 5 business days of incident
- Draft timeline from incident channel, status-page log, and metrics
- Identify contributing factors (not 'root cause') with the team
- Capture what went well + what went poorly in the discussion
- Convert action items into separate linked Jira issues with owners
- Publish postmortem document to the team-readable archive
- Track action items to closure - revisit at next postmortem
Common questions
What does 'blameless' mean for a Jira postmortem?
Blameless means the postmortem treats individual decisions as system outputs - if a human did the wrong thing, the question is why the system made that decision look correct. The postmortem document never names a person as the cause; it names system conditions, missing checks, or process gaps. This is what makes engineers willing to write honest postmortems.
How soon after an incident should a Jira postmortem happen?
Within 5 business days. Sooner is better - memory degrades fast. The single biggest cause of useless postmortems is waiting two weeks until 'we have time', by which point nobody remembers what happened. Make 'schedule postmortem' a sub-task on the incident ticket so it can't be forgotten.
Should postmortem action items live on the postmortem ticket or as separate Jira issues?
Separate issues, linked to the postmortem. Action items need owners, due dates, and to appear on individuals' boards. The postmortem ticket is the meeting record and the source of truth for what was decided; the action-item tickets are how the decisions actually get implemented.
Who should facilitate a Jira postmortem?
Someone NOT on-call during the incident. The on-call engineers are subjects of the postmortem and can't be neutral facilitators. Most mature teams rotate a facilitator role - often an EM or staff engineer from a different on-call rotation - explicitly so the on-call can speak honestly without facilitating their own review.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →