Status page: investigating (within 15 minutes)
We are investigating reports that [customers are unable to COMPLETE ACTION]. We are aware of the issue and are actively working on it. The next update will be posted by [TIME].
Incident Communication Templates
Incident communication is written badly because it is written under pressure by someone who is also fixing the problem. Pre-written templates with the gaps marked let the first update go out in two minutes rather than forty.
What you get
- Status page updates for each stage from investigating to resolved
- Customer email templates, including the difficult ones
- Internal and executive update formats
- Rules on what not to say while an incident is live
How to use this template
- 1
Publish something within fifteen minutes. The first update does not need a cause. It needs to say you know, what customers are experiencing, and when you will update again. Silence is interpreted as not knowing.
- 2
Commit to a next update time and keep it. Always state when the next update comes, and publish then even if nothing has changed. 'Still investigating, next update at 11:30' maintains trust; silence destroys it.
- 3
Describe impact, not architecture. Customers do not care which service degraded. They care whether they can check out, log in, or receive their data. Write the impact in terms of what they cannot do.
What's inside
Here's a preview. Unlock the free download to get all 6 sections (5 more below).
Related templates
More free templates IT teams use alongside this one.
Incident Response
Get templateIncident Severity Matrix
Most severity matrices fail in the one moment they matter: at 02:00, when a tired engineer has to decide whether to wake anyone. This one is written so the level is readable off customer impact alone: no judgement call about root cause, no guessing how bad it might get.
Incident Response
Get templateIncident Response Plan Template
Security incident response plans are usually written for an auditor and discovered to be unusable during the first real incident. The sections that matter are the ones you read in the first hour: who decides, who to call, and what not to touch.
Incident Response
Get templateMajor Incident Review Template
A major incident review is not a longer postmortem. Its job is to examine how the response itself performed (whether detection, escalation, communication, and decision-making worked), which is a different question from what broke.
Frequently asked questions
How quickly should you post the first incident update?
+
Within fifteen minutes of confirming customer impact. The first update does not need a cause. It needs to acknowledge the issue, describe what customers cannot do, and commit to a next update time.
What should an incident status update say?
+
What customers are experiencing in their own terms, what you are doing, any workaround, and when the next update will come. Avoid architecture, speculation on cause, and restoration estimates you cannot stand behind.
Should you publish a public postmortem after an incident?
+
Only if you will actually do it. A promised review that never appears damages trust more than never offering one. If you do publish, be specific about the preventive actions rather than describing the technical failure in detail.