Customer support
Write an outage update from confirmed incident facts
An outage update tells customers which service is affected, what they may notice, what they can do meanwhile and when you will write again. Build it only from facts the incident team has confirmed. Leave out causes and repair estimates until someone has verified them.
Affected service, as customers name it: [ ] Who confirmed the impact, and when: [ ] Observed impact customers may see: [ ] Who is affected and who is not: [ ] Workaround: [ ] Workaround tested by: [ ] Next update promised for: [time and time zone] Person responsible for sending it: [ ] Unconfirmed items kept out of the message: Cause: [ ] Restoration estimate: [ ] Resolution status: [ ] Approved by: [ ] Channel and time sent: [ ]
Statements that outrun the facts
For each sentence, ask who confirmed it and when. Outage drafts often add a cause such as a vendor or a deployment, a vague estimate such as "soon" or "within the hour", or "we have fixed it" when engineers have only seen early improvement. Check that the service is named the way customers know it, not by an internal system name. Confirm the next update time includes a time zone and that one person owns sending it. If your team has not tested the workaround, say so or omit it.
Compare this outage update against the confirmed facts I listed. Quote every phrase that states or implies a cause, a restoration estimate, or that the problem is fixed, and propose wording that stays within the confirmed facts. Then check that the next update time includes a time zone and that the affected service uses the customer's name for it.
Publish, then keep the promise
Have the incident owner approve the wording, then send it through your normal status channel. Assign the promised update time to a named person. When that time arrives, send an update even if nothing has changed, and say what is still true. Once resolution is confirmed, write a separate closing message and record which facts were verified.