During an outage, customers usually want three things: what is affected, what they should do, and when they will hear more. You do not need a confirmed root cause to answer the parts you know.
The examples below are fictional templates. Replace every bracketed field with verified information before publishing.
Investigating
We are investigating [symptom] affecting [service or feature]. [Known scope, if confirmed.] Our next update will be by [time and timezone], even if the investigation is still ongoing.
Prefer “some requests are failing” over “the platform is down” when the scope is still unclear. Do not call an incident minor before understanding its impact.
Mitigating
We have identified [confirmed issue at an appropriate level of detail] and are applying [safe public description of the mitigation]. [Feature] remains affected. [Verified workaround, if available.] Next update: [time and timezone].
Describe customer impact before infrastructure detail. Avoid disclosing internal addresses, security-sensitive configuration, or customer identifiers.
Monitoring recovery
We have applied the mitigation and are seeing [observed improvement]. We are monitoring recovery before marking the incident resolved. [Any remaining impact.] Next update: [time and timezone].
“A fix has been deployed” is not the same as “customers can use the service again.” Check the affected path and any accumulated backlog.
Resolved
[Service or feature] has recovered as of [time and timezone]. The incident affected [confirmed scope] between [start] and [end]. [Remaining customer action, or confirmation that none is required if verified.] We will share [follow-up, only if committed].
If the start time is uncertain, say “first detected at” rather than presenting the monitor's timestamp as the exact beginning of impact.
Promise the next update, not an invented repair time
You can control when you communicate more reliably than when an unknown fault will be fixed. Choose a cadence your team can sustain. If there is no new finding, say that and explain what is still being checked.
Save these templates before an incident. Then make sure the place you publish them is reachable when your application is not. Our guide to a status page that survives its own outage covers that separation. Hosted public status pages are a ZnowPulse Pro feature; see the current plans.