How to write a customer incident report

You owe a client or customer an explanation for an outage, and you are an engineer, not a writer. This guide gives the seven parts a customer report needs, in the order readers want them, with a before-and-after example. The example incident is invented.

The seven parts, in order

1. Summary. Two or three sentences: what happened, how long, and whether it is over. Many readers stop here.
2. Impact. Who could not do what, from when to when. Use only what your logs and tickets show. If you do not know how many people were affected, say so.
3. Timeline. One line per event with a time and a time zone. Include when you first noticed, not only when it started, because the two are rarely the same.
4. Cause. What you have confirmed, labelled as confirmed, and what you only suspect, labelled as not yet confirmed. A symptom ("the server crashed") is not a cause; the question is what let it become an outage.
5. Resolution. What restored service. A restart or workaround is not the same as a fix; say which it was.
6. What happens next. Only follow-ups you have decided on, each with an owner and a date. If nothing is decided yet, say when you will tell them.
7. Contact. A real person or address for questions.

This follows the shape used by public engineering guides such as Google's SRE book chapter on postmortem culture and Atlassian's incident handbook, trimmed to what a customer needs rather than what an internal review needs.

Before and after

Before (notes pasted from chat)

09:12 502 on booking page. 09:20 ack. 09:31 disk full, debug logging on after the 08:45 deploy. 09:48 cleared logs, restarted, back. 37 failed bookings in the app log.

After (the customer version)

Summary: On Friday 3 Oct the online booking page was unavailable until 09:48 UTC. It is working again. We are sorry for the disruption.
Impact: People trying to book online saw an error. We first detected the problem at 09:12 UTC. The app log shows 37 failed booking attempts and no lost data.
Cause (confirmed): An update at 08:45 UTC switched on detailed logging by mistake. The log files filled the server's disk.
Resolution: We cleared old logs and restarted the application at 09:48 UTC.
What we are doing next: [follow-up, owner and date: not yet decided]

Notice what the rewrite does not do. It does not name the engineer who deployed, does not say "it will never happen again", does not offer a credit, and does not say the failure started at 09:12 (that is when it was detected). The one thing it cannot fill in, the follow-up, is left as a visible blank instead of a made-up promise.

Seven mistakes that cost trust

• Writing the start of the outage as the time you noticed it.
• Promising "it will never happen again" or a credit you have not agreed.
• Naming the person who made the change, or writing "human error" and stopping there.
• Listing a suspicion as the cause.
• Leaving out the time zone.
• Using internal words such as RCA, failover or sev2 without explaining them.
• Sending it a week later. Send a short holding note the same day and the full report within a few working days.

Check it for free, or get a draft

Paste your timeline and draft into the free timeline calculator and report checker. If you would rather start from a full draft made from your own notes, with missing times and causes left as marked blanks, see the paid draft service ($9, AI-written by Claude, not legal advice).