Incident report template

Consistency matters more than elegance here. A reader comparing two incidents should not have to work out where the same fact lives in each.

Copy the structure below. Leave a section out only when it genuinely does not apply, and say so rather than deleting it silently.

#Header table

Three fields, chosen for the incident. Use Atlassian ticket references where the cause was a platform incident.

#Sections, in order

• What happened. Plain language. Say early whether the cause was ours or the platform's.

• Timeline (UTC). Detection, escalation, identification, fix, recovery. Omit if the incident was not time-boxed.

• How you would have known. The symptoms a customer saw, so they can match this report to their experience.

• Customer data. Always present. State plainly what was and was not affected.

• Resolution. What fixed it, and what if anything customers had to do.

#Rules

• Never invent a timestamp. If a time is not known, leave it out rather than approximating it silently.

• Say what was not affected as well as what was. It is usually the more useful half.

• Link the report from the affected product's troubleshooting section.

• Date the page title by month and year, so a list of them reads chronologically.

#A few things worth knowing

• An incident with no customer-visible symptom does not need a public report. One that customers noticed does, even if it was brief.

• Write it while the detail is fresh. A report published a month later is an archaeology exercise.

• The template is a floor, not a ceiling. Add a root cause section when the cause is interesting.

#Related

Same shape every time. That is the point.