# 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 | **Field** | **Example** | | ------------------------------ | ---------------------- | | Severity | P1, P2, or Degradation | | Duration | 2 hours 40 minutes | | Scope, impact or affected apps | Diagram rendering only | 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 [Service incidentsReports written to this template.](https://help.gocapable.com/trust/service-incidents.html) --- _Same shape every time. That is the point._