How to Write an Incident Report That Fixes the Problem

An incident report records what broke, what it broke, who it touched, and what you did about it. It is the paper trail every operations, security, and support team relies on after something goes wrong. Write it right and the next person handles the same failure in half the time. Write it wrong and the same outage happens again six months later because nobody wrote down the cause.

This guide covers how to write an incident report that your team can actually use: the sections to include, a template you can copy, a filled-in example, and the habits that turn these documents into noise.

Why Incident Reports Exist

An incident is any event that disrupts a service or puts data, money, or people at risk. The report is the record that outlives the firefight. Three things happen because of it.

First, it gives leadership a factual account without the rumor. During an outage, ten people will tell the CEO ten different stories. The report is the single source of truth.

Second, it protects the people who responded. A clear timeline shows who did what under pressure. That matters when someone asks why a fix took as long as it did.

Third, and most important, it stops the repeat. A good report ends with a root cause and an action. A bad one ends with "resolved." The teams that improve are the ones that close the loop on paper.

What Goes in an Incident Report

An incident report needs to answer six questions: what happened, when, who was hit, how bad was it, what did we do, and why did it happen. Miss any of these and the document is incomplete.

Include these sections:

• Header — a title, an incident ID, the date, the author, and a severity rating (SEV-1 through SEV-3 or similar).
• Summary — two or three sentences a busy executive can read in ten seconds.
• Timeline — timestamps in your real timezone, from first symptom to full recovery.
• Impact — who was affected, for how long, and what they could not do.
• Root cause — the actual trigger, not the symptom. "The server crashed" is a symptom. "A bad config pushed at 2am removed the failover" is a cause.
• Resolution — the steps taken to restore service.
• Follow-up actions — owned tasks with names and dates so the same bug does not return.

Keep the language plain. Write "the database connection pool filled up" not "a degradation in connection availability was observed." The reader needs facts, not cover.

Template

Copy this structure for any incident, technical or not:

# Incident Report: [Short Title]

Incident ID: INC-2026-001
Date: 2026-10-29
Author: [Your name]
Severity: SEV-2

## Summary
[2-3 sentences: what broke and who it affected]

## Timeline
- 09:14 — First alert fired (error rate spike)
- 09:21 — On-call engineer acknowledged
- 09:48 — Root cause identified (deploy #482)
- 10:30 — Fix deployed, error rate normal

## Impact
- Affected: 3,200 active users
- Duration: 76 minutes
- Lost capability: checkout and order history

## Root Cause
[A single sentence stating the trigger, not the symptom]

## Resolution
[Steps taken to restore service]

## Follow-up Actions
- [ ] Roll back deploy #482 — Owner: @name — Due: 2026-10-29
- [ ] Add deploy guardrail for payment path — Owner: @name — Due: 2026-11-05

Real Example

Here is a filled-in report for a real type of failure:

# Incident Report: Checkout Timeout After Payment Deploy

Incident ID: INC-2026-047
Date: 2026-10-29
Author: Dana Okafor
Severity: SEV-1

## Summary
A deploy to the payment service introduced a slow query that exhausted the
database connection pool. Customers could not complete checkout for 76 minutes.

## Timeline
- 09:14 — Alert: checkout error rate passed 5%
- 09:21 — On-call (Dana) acknowledged, opened incident channel
- 09:40 — Found connection pool at 100%, requests queuing
- 09:48 — Traced to deploy #482 shipped at 08:55
- 10:05 — Rolled back deploy #482
- 10:30 — Error rate back under 0.5%, incident closed

## Impact
- Affected: 3,200 active users across EU region
- Duration: 76 minutes (09:14 to 10:30)
- Lost capability: payment and order history pages

## Root Cause
Deploy #482 added a missing index scan on the orders table, forcing a
full-table scan under load that pinned every connection.

## Resolution
Rolled back #482, restored pool health, confirmed via synthetic checkout.

## Follow-up Actions
- [x] Roll back deploy #482 — Owner: Dana — Done
- [ ] Add connection-pool saturation alert at 80% — Owner: Sam — Due 2026-11-02
- [ ] Block payment-path deploys during EU peak — Owner: Priya — Due 2026-11-05

Common Mistakes

Most incident reports fail the same way. Avoid these:

1. Blaming a person instead of a system. "Jim pushed a bad deploy" closes nothing. "The deploy path had no guardrail for the payment service" opens a fix. Write for the next failure, not the next performance review.
2. Writing the timeline from memory after the fact. You will get the times wrong. Log them as they happen, or pull them from your monitoring tools before you write.
3. Confusing the symptom with the cause. "The site was down" is not a root cause. Keep asking why until you hit a process or code change you can point to.
4. Skipping follow-up actions. A report with no owners and dates is a diary entry. Assign every action to a name and a deadline, or the same incident returns.
5. Hiding impact to look better. Understating the user count or duration destroys trust the moment someone checks the logs. State the real numbers.

Write Your First Report Today

Pick the last thing that broke on your watch and write it up using the template above. If you keep a daily report or a weekly report, link the incident inside it so leadership sees the connection between daily work and service health. For a structure you can reuse across other report types, see our sales report guide. The teams that document incidents well are the teams that stop having them.