Blog
A practical structure for incident status updates: what is affected, what users should do, when the next update comes, plus templates for each stage and common mistakes.
To write an incident status update, state what is affected in user terms, say what users should do right now, and commit to a time for the next update. Label it with the current stage (investigating, identified, monitoring or resolved) and keep it short enough to read in ten seconds. Everything else, including root cause details, can wait for later updates or the postmortem.
This guide gives you a reusable structure, copy-ready templates for each incident stage and a list of wording mistakes that reliably turn one outage into fifty support tickets.
Readers of a status update are not trying to understand your infrastructure. They want to know whether the problem explains what they are seeing and whether they need to act. A good update answers three questions for the reader: am I affected, what should I do right now, and when will I hear more.
In practice that translates into five elements:
If you are not sure what belongs on the page around these updates, the guide on what a status page is and what to put on it covers components, history and subscriber notifications.
When an alert fires, nobody wants to stare at a blank text box. Follow the same sequence every time so the first update goes out within minutes:
The templates below use square brackets for the parts you fill in. Keep the sentence order, it mirrors the questions readers ask.
Post this as soon as you have confirmed impact. Speed matters more than detail here: an honest we are looking into it within five minutes beats a perfect explanation after forty.
Investigating - [Component] is [symptom, e.g. returning errors / loading slowly] We are investigating reports that [symptom in user terms] for [scope, e.g. some customers in the EU region]. [Other components] are working normally. What you can do: [action, e.g. If a payment fails, please do not retry more than once to avoid duplicate charges.] Next update by [HH:MM UTC].
Use this stage when you know what is broken and are working on a fix. Share the cause at a level customers can understand, without blaming a vendor or an individual.
Identified - [Component] [symptom] We have identified the cause: [plain-language cause, e.g. a configuration change to our database cluster reduced capacity]. We are [action, e.g. rolling back the change]. [Scope statement, e.g. Customers on the US region are not affected.] What you can do: [action or No action is needed on your side.] Next update by [HH:MM UTC].
A fix is deployed and metrics are recovering, but you are not yet confident. Say what users might still notice, such as a backlog being processed.
Monitoring - Fix deployed for [component] We have deployed a fix and [component] is recovering. Error rates are back to normal levels. [Residual effect, e.g. Emails queued during the incident are being delivered and may arrive with a delay of up to 30 minutes.] What you can do: [action, e.g. If you still see errors after 15:00 UTC, contact support with the request ID.] We will continue monitoring and post an update by [HH:MM UTC].
Close the incident with the exact time window, the impact and any follow-up. If data was lost or delayed, say so here, not only in a private email.
Resolved - [Component] [symptom] This incident is resolved. Between [HH:MM] and [HH:MM UTC], [scope] experienced [symptom]. [Data impact, e.g. No data was lost. / Webhooks sent during this window were delayed but delivered.] [Follow-up, e.g. We will publish a summary of the cause and the changes we are making by [date].] We apologize for the disruption.
The cadence should match how uncertain the situation is. A reasonable default many teams use:
The rule that matters more than any interval: post an update by the time you promised, even if the content is No change, we are still working on the rollback. Silence after a promised time is read as chaos.
Avoid estimated resolution times unless you are confident. Fixed within 10 minutes that turns into two hours damages trust more than We do not have an estimate yet.
Most incident-related tickets are not caused by the outage itself but by updates that leave a question open. These are the patterns to watch for:
A typical first draft written under pressure:
We are aware of an issue affecting some services and our engineers are working on it. Sorry for the inconvenience.
It confirms that something is wrong and nothing else. Every reader still has to ask: which services, am I affected, should I do something, when will I know more.
The same update, rewritten with the five elements:
Investigating - Dashboard login failing for some users. Since 09:42 UTC, some users see an error when signing in to the dashboard. The API and scheduled reports are working normally. If you are already logged in, your session remains active, so please do not log out. Next update by 10:15 UTC.
It is barely longer, but it answers all the questions that would otherwise arrive as tickets, and it adds a user action that actively reduces impact.
If you use m0nitor, the incident management features let you store reusable incident templates with placeholders, so the structure above can be saved once per stage and filled in during an outage. Each incident keeps a timeline of updates from start to resolution, and scheduled maintenance windows are announced on the status page in the same way. The incident documentation describes how to open an incident, post updates, apply templates and resolve it. Any status page tool or even a static page works with the templates in this article, as long as the team agrees on the structure before the next outage.
Most updates fit in three to five sentences. The reader should be able to understand whether they are affected and what to do within a few seconds. Put detailed technical explanations in the resolved update or a separate postmortem, not in the live updates.
Only at the level customers can understand and only once you are confident, which usually means the identified stage or later. During investigating, speculation about causes tends to be wrong and has to be corrected publicly. A full root cause analysis belongs in a follow-up summary after resolution.
Post an update anyway. Say what you are currently doing, confirm that the impact is unchanged and set a new next update time. A short no change update keeps users on the status page instead of in your support queue.
Ideally someone other than the engineer fixing the problem, often called the communications lead or incident commander. They gather facts from the responders, write the update with the agreed template and keep the update schedule, so the people debugging are not interrupted every 20 minutes.