How to Write a Useful Incident Update

Customers need four things in a public incident update: facts they can verify, the action you are taking, when you will speak again, and a tone that does not panic them. Speculation, silence, and marketing language all make outages worse. This guide gives a paste-ready template.

Assumption: you have a status page or another channel customers already trust. Do not invent a new medium mid-incident.

The FACT template

• Facts. What is broken in customer language. What still works. Timestamp in a clear timezone.
• Action. What you are doing now. Avoid promising a root cause you do not have.
• Cadence. When the next update lands, even if nothing changed.
• Tone. Short sentences. No blame. No jokes about downtime. No vague reassurance.

First update (within minutes)

Publish as soon as you know customers are affected, even if the cause is unknown.

Progress update

Say what changed since the last message. If nothing changed, say that and keep the cadence.

Resolution update

State when service returned, what customers should retry, and whether a follow-up postmortem is coming. Do not claim perfection.

Internal notes versus public updates

Cadence under pressure

For active customer impact, update every 30 to 60 minutes unless you promise a specific time. Missing a promised update without explanation destroys trust faster than a delayed fix. Related glossary: incident, public incident.

When not to publish

• A brief blip that never left the verifying state and no customer reported impact
• A staging-only failure
• A security event that requires controlled disclosure (follow your security process instead)

Language that helps

• Started at 13:52 UTC
• Checkout is failing for some customers
• Next update by 15:00 UTC
• Retry the payment if it failed during the window

Language that usually hurts: forever words (always, never), blame, fake precision, and promises about root cause before you have one. If you do not know, say you are investigating.

Practice once while calm

Write three draft updates for a fictional outage before you need them. Store them where on-call can find them. Pair with What Should Go on a Public Status Page? so components and language already match.

When the real incident hits, you should be editing timestamps and impact, not inventing a voice. That is the whole point of the FACT template.