Post-incident review example: a complete customer report, annotated

If you are searching for a post-incident review example, most of what you find is an internal template with blank headings. This page shows one finished customer-facing report, written for a small SaaS team after a login outage, with a note under each part explaining why it is written that way. The company, product and numbers are invented; reuse the structure, not the facts.

The scenario (invented)

Acme Rota is a made-up scheduling app for small clinics' front desks. On a Tuesday morning customers could not sign in. The cause turned out to be an expired TLS certificate on the login subdomain. The raw notes the team had were a Slack scroll-back, a monitoring alert time and one ticket count. The report below is what they sent to customers two days later.

The report

Subject: Report on Tuesday's sign-in outage

Summary. On Tuesday 6 October, between 07:52 and 09:14 UTC, customers could not sign in to Acme Rota. Staff who were already signed in could keep working. Sign-in has worked normally since 09:14 UTC. We are sorry for the disruption to your morning.

Why: the first paragraph is the only one most readers finish, so it carries the start, the end, the effect and the current state. The time zone is written once and used everywhere.

Impact. The sign-in page showed a browser security warning, and customers who continued saw an error. Our support inbox received 23 tickets about this in the period. We do not yet know how many people tried and gave up without writing to us. No data was lost or exposed.

Why: it counts only what the team can show (23 tickets) and says plainly what it cannot know. "No data was lost or exposed" is included because the team checked, and the report says so only because it is true.

Timeline (all times UTC).

07:52  The login certificate expired. (From the certificate's own expiry time.)
08:20  First customer ticket received.
08:34  Monitoring alert fired. Nobody was watching that channel until 08:41.
08:41  On-call engineer acknowledged the alert.
08:58  Cause identified: expired certificate on the login subdomain.
09:06  New certificate issued and installed.
09:14  Sign-in confirmed working from three networks.

Why: the first line is when the problem began, not when anyone noticed. The 42 minutes between 07:52 and 08:34 are visible instead of hidden. Noticing (08:20), alerting (08:34) and acting (08:41) are separate lines because customers judge each gap differently.

Cause (confirmed). The certificate for the login subdomain was renewed by hand each year. This year's renewal reminder went to a mailbox that nobody reads any more. The main website certificate renews automatically, which is why only sign-in was affected.

Why: a symptom ("the certificate expired") is not a cause. The cause is the gap that let it expire. It is described as a process failure, not a person, and it is labelled confirmed because the team checked the reminder mailbox.

Resolution. We issued a new certificate and installed it. This restored sign-in. It did not fix the underlying renewal process; that is covered below.

Why: it separates the repair from the fix. A reader who sees both knows whether to expect a repeat.

What happens next.

• Move the login certificate to automatic renewal. Owner: platform lead. Date: Friday 9 October.
• Add an alert 14 days and 3 days before any certificate expires. Owner: on-call engineer. Date: Friday 16 October.
• Send alerts for after-hours incidents to a phone, not a chat channel. Owner: engineering manager. Date: to be decided; we will tell you by Friday 9 October.

Why: each action has an owner and a date, or an honest date for when the date will be known. There is no "we will do better" and no promise that this never happens again.

Contact. Questions about your account: [email protected] (invented address).

What this report deliberately leaves out

• A credit or refund. Nobody with authority had agreed one, so the report does not offer one. If your contract has an SLA credit, say how to claim it only when you are sure.
• The name of the person who missed the reminder. The failure was a reminder that went to an unread mailbox, which is a process problem.
• A guessed number of affected users. "23 tickets" is a fact; "around 400 users" would have been an invention.
• Internal vocabulary. "TLS" is explained as a security certificate on first use, and there is no "RCA", "sev1" or "failover".

How to adapt it

1. Write your own timeline first, one line per event, in one time zone. The free timeline calculator turns it into detection time, repair time and total duration.
2. Fill in the seven parts in the order above. Anything you do not know becomes a visible blank such as [start time: not confirmed] rather than a guess.
3. Check the draft against the same parts in the report checker before you send it.
4. During the incident itself, post short updates with the status page templates. The longer guide to customer incident reports explains each of the seven parts and the common mistakes.

The structure follows public guidance such as Google's SRE book on postmortem culture and Atlassian's incident postmortem guide, trimmed to what a customer needs.

If you would rather start from a draft

Paste your own incident notes into the $9 draft service and get a report like this one, plus a status-page post and a cover email. It is written by Claude (AI) only from your notes, and times, causes or numbers you did not give are left as marked blanks. It is not legal advice.