Incident report template: what a good software incident report includes

An incident report is the record of what happened during an incident: what broke, who was affected, what the team did, and what changes will follow. It’s the document leadership, customers, auditors and the next on-call engineer rely on. The retrospective is where the team learns from it; the report is what everyone else reads.

What does a good software incident report include?

A good incident report answers six questions in the first screen: what happened, when, how bad it was, who was affected, what fixed it, and what will change. Everything else supports those answers. The fields that matter most:

• Summary. Two or three sentences a non-engineer can understand.
• Severity and status. The severity level at its peak and whether the incident is resolved.
• Impact. Affected services and features, customers or requests affected, duration, and any data or financial impact.
• Timeline. Detection, declaration, key decisions, mitigation and resolution, with timestamps.
• Response. The incident commander, responders and roles, and what each did.
• Cause. The trigger and the contributing factors, written without blame.
• Action items. Each with an owner, a due date and a link to the ticket.
• Communication. When the status page and stakeholders were updated, and what they were told.

Incident report template

Copy this into your docs tool or incident platform and adapt the headings to your severity levels.

# Incident report: [short title]

**Incident ID:** INC-[number]
**Severity:** SEV-[1–4] (peak)
**Status:** Resolved | Monitoring | Ongoing
**Incident commander:** [name]
**Report owner:** [name]
**Dates:** Started [YYYY-MM-DD HH:MM UTC], resolved [YYYY-MM-DD HH:MM UTC]

## Summary
[Two or three plain-language sentences: what happened, who was affected, how it was resolved.]

## Impact
- Services and features affected: [list]
- Customers or requests affected: [number or percentage]
- Duration of customer impact: [hh:mm]
- Data, security or financial impact: [none | description]

## Timeline (UTC)
| Time | Event |
| ---- | ----- |
| HH:MM | First alert or customer report |
| HH:MM | Incident declared, commander assigned |
| HH:MM | First status page update |
| HH:MM | Mitigation applied |
| HH:MM | Service restored |
| HH:MM | Incident resolved |

## Response
- Roles: [commander, communications lead, technical leads]
- Key decisions and why they were made: [list]

## Cause
- Trigger: [the event that started the incident]
- Contributing factors: [conditions in the system or process that allowed it]

## Action items
| Action | Owner | Due | Ticket |
| ------ | ----- | --- | ------ |
| [change] | [name] | [date] | [link] |

## Communication
- Status page updates: [times and summary]
- Stakeholder updates: [who was told what, and when]

For the longer document the team uses to learn from the incident, see the retrospective template.

What should you do if incident reports are inconsistent across teams?

Standardize the template and the required fields, and leave the writing style to each author. Inconsistent reports usually come from each team starting with a blank document, so the same incident gets described three different ways depending on who writes it up. Rootly generates every report from the same structure, with the timeline captured during the incident.

1. Use one shared template with required fields: severity, impact, timeline, cause, action items.
2. Define the severity levels once and link to them from the template, so SEV-2 means the same thing everywhere.
3. Capture the timeline automatically instead of reconstructing it afterwards. Reconstructed timelines are where most of the inconsistency comes from.
4. Review a sample of reports each month for missing fields rather than for writing style.

In Rootly, every incident produces its report from the same structure: retrospective templates can be customized per team or incident type while keeping required fields, and the timeline is captured automatically during the incident.

What is the best way to document software incidents as they happen?

Capture the record inside the tool where the response happens, so documentation happens as a side effect of responding. Keep the incident in one channel, log decisions there as they are made, and let the timeline build from alerts, messages and deploys. Rootly builds that timeline automatically in Slack or Microsoft Teams while the incident runs.

Rootly does this from Slack or Microsoft Teams: Rootly AI pulls timestamps from alerts, chat messages, commits, deploys and status updates into the incident timeline while the incident is running, a meeting bot transcribes the incident bridge, and when the incident closes the retrospective is drafted from that record as a separate document the team reviews and edits. Reports can be exported to Confluence, Google Docs, SharePoint or Notion.

Frequently asked questions

What does a good software incident report include?

A summary, severity, impact, a timestamped timeline, the response and roles, the trigger and contributing factors, owned action items, and a record of customer and stakeholder communication. Rootly captures the timeline, roles and severity during the incident, so most of the report exists before anyone starts writing.

What should we do if our incident reports are inconsistent across teams?

Use one template with required fields, define severity levels once, and capture the timeline automatically instead of rebuilding it from memory. Rootly generates every report from the same structure and captures the timeline during the incident.

What is the best way to document software incidents as they happen?

Run the incident in one channel and let the timeline build from alerts, messages and deploys as they happen. Rootly captures that timeline automatically in Slack or Microsoft Teams and drafts the retrospective from it.

What is the difference between an incident report and a retrospective?

The incident report is the factual record for readers outside the response team: what happened, the impact and what will change. The retrospective is the team’s working session and document for learning from the incident. The report usually summarizes the retrospective’s findings and action items.