Skip to content
IncidentBot

Product

Solutions

Resources

Log in

Incident postmortems written from the timeline

The value of an incident is in what the team learns from it, and that learning usually dies in an empty document a week later. IncidentBot captures the timeline while the incident is running, so when you resolve it the postmortem already has the facts: when the alert fired, who was paged, when they acknowledged, what was tried, what customers were told and when service recovered. Your team spends the review on causes and fixes instead of reconstructing what happened.

Run a sample incident

Postmortem INC-2481, checkout-api latency

Draft
SectionFilled in from the timeline
Impact window 14:02:11 to 14:41:05
Time to acknowledge 6m 29s
Time to resolve 38m 55s
Timeline 8 events, alerts to resolution
Action items 2, synced to Jira

A post mortem incident record that builds itself during the incident

Everything that happens through IncidentBot is written to the timeline with a timestamp and a name. The scribe marks important Slack messages with a reaction or /incident note, and they join the record.

Run a sample incident
  • Alert received, grouped and routed, with the source and labels.
  • Pages sent, acknowledgements, escalations to the next tier.
  • Role assignments, severity changes and status changes.
  • Status page updates exactly as customers saw them.
  • Marked messages from the incident channel, including links to graphs and deploys.
  • Resolution time, with MTTA and MTTR calculated from the same record.

Blameless postmortem template your team will fill in

When the incident is resolved, IncidentBot opens a postmortem draft in the blameless format. The factual parts are filled in from the record, and the parts that need human judgment are left as clear prompts.

  • Summary: what happened, who was affected and for how long, prefilled from the incident fields.
  • Impact: affected services and components, duration, severity, status page updates.
  • Timeline: the captured events, editable, in order.
  • Contributing factors: prompts that ask about conditions and decisions, not about people.
  • What went well and what was hard: detection, paging, diagnosis, communication.
  • Action items: owners, due dates and links to tickets.

Blameless means systems, not culprits

A blameless postmortem assumes people made reasonable decisions with the information they had, and asks what in the system made the failure possible. The template is written that way on purpose: it asks what signals were missing, which runbook step was unclear, which alert fired too late. That is how teams keep getting honest reports.

Action items that end up in the backlog

A postmortem is only useful if its action items get done. On Team and above, each action item is created as an issue in Jira or Linear with a link back to the incident, and its status syncs back to IncidentBot.

  • See open action items per service and per team, and which incidents they came from.
  • Spot repeat incidents on the same service whose previous action items are still open.
  • Close the review when the linked items are done, not when the document is saved.

Incident postmortem template for every severity

Not every incident deserves a two-hour review. You can set a short template for SEV3 and SEV4 and the full review for SEV1 and SEV2, and decide which severities require a postmortem at all. If you want to design your own format first, our postmortem template guide walks through each section.

What your postmortems add up to

Individual reviews teach one lesson. Across a quarter, the record shows patterns: the services with the most incidents, the longest time to acknowledge, the teams carrying the most pages. MTTA and MTTR reports and the on-call load report sit in incident tracking, built from the same timelines as your postmortems. Per-service SLA and uptime reporting is part of Business.

Postmortems on each plan

Starter includes the incident timeline and a basic postmortem template. Team adds postmortem drafts prefilled from the timeline, action items synced to Jira and Linear, and MTTA and MTTR reports. Business adds the service catalog with ownership, so postmortems and action items roll up to the owning team. See the pricing page for everything in each plan.

See pricing

Questions

Can we edit the timeline before the review?

Yes. You can add missing events, correct descriptions and hide noise. The original captured events are kept in the history, so edits are visible.

Does the postmortem draft write the root cause for us?

No. The draft fills in facts from the record. Contributing factors and conclusions are written by the people who ran the incident, because that is where the learning happens.

Can people outside engineering read the postmortem?

Yes. Stakeholder viewers are included on every plan and are not billed, so support, product and leadership can read postmortems without a responder seat.

Where does the incident start?

Usually in Slack. The Slack incident management page shows how /incident opens the channel and starts the timeline that becomes the postmortem.

Turn your next incident into a review that gets done

Resolve the incident, open the draft and spend the meeting on what to change. You can see the timeline and draft on a sample incident in the incident response platform demo before you create an account.

Run a sample incident