Use casesIncident postmortem tracker

Build your incident postmortem tracker.

Connect incident timelines, contributing factors and follow-up owners.

How to build your incident postmortem tracker

  1. Describe the job

    Connect incident timelines, contributing factors and follow-up owners.

  2. Review the first version

    Choose how the support analyst records the incident and how the engineering owner reviews the next step.

  3. Refine the views

    Ask First to adjust the fields and views for the people who will use the app.

  4. Test before sharing

    Walk through the process with a sample record and check who owns the next action.

A incident postmortem tracker example

A service review identifies a retry problem but its proposed action has no verification method.

Illustrative workflowIncident postmortem tracker

Incident postmortem tracker example

Record
Incident postmortem tracker · 01
Owner
Support analyst

Current stage · Support analyst

Open the incident

A service review identifies a retry problem but its proposed action has no verification method.

Read the full walkthrough
  1. Open the incident

    A service review identifies a retry problem but its proposed action has no verification method.

    Record:
    Incident postmortem tracker · 01
    Owner:
    Support analyst
  2. Review the verification

    Add a measurable check and keep the action open until evidence is recorded.

    Stage:
    Awaiting engineering owner review
    Owner:
    Engineering owner
  3. Keep the corrective action open

    Keep the corrective action open until its result is verified.

    Next action:
    Keep the corrective action open until its result is verified.
    Owner:
    Release reviewer

What to include in your incident postmortem tracker

  • Keep the incident in context

    Keep incident, timeline, observation, contributing factor, action owner and verification together so the next person can understand the request or record.

  • When the next step needs a decision

    A service review identifies a retry problem but its proposed action has no verification method. Add a measurable check and keep the action open until evidence is recorded.

  • Keep verification visible

    Keep the corrective action open until its result is verified.

  • Choose what each person needs

    Give the support analyst a working view and the engineering owner a review view. Keep incident and timeline attached to the decision as the work moves between them.

Questions about incident postmortem tracker

Start with incident, timeline, observation, contributing factor, action owner and verification. Describe who enters the information and who reviews the next step.

Build your incident postmortem tracker.

Start with your workflow and make it yours.

Get started