# How to Write a Useful Incident Update
Customers need verifiable facts, a clear action, a next-update time, and a calm tone. Speculation and silence both make outages worse. This guide gives a paste-ready template and examples.
Author: fajita-editorial
Published: 2026-07-17
Updated: 2026-07-17
Last reviewed: 2026-07-17
Version: 1
Canonical: https://fajita.io/blog/write-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.

> NOTE: We are investigating reports that API requests are failing with timeouts. Sign-in and billing pages may be slow or unavailable. Dashboard read views appear unaffected. Next update by 14:30 UTC.

## Progress update

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

> NOTE: Investigation continues. We confirmed elevated error rates on the payments API beginning at 13:52 UTC. Checkout is degraded. We are failing closed on new charges while we roll forward a fix. Next update by 15:00 UTC.

## Resolution update

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

> NOTE: The payments API recovered at 14:48 UTC. Error rates are back to normal. If a checkout failed during the window, retry the payment. We will publish a short summary of cause and follow-ups within two business days.

## Internal notes versus public updates

| Keep internal | Publish externally |
| --- | --- |
| Suspect commit hashes, vendor tickets | Customer-visible impact |
| Blame hypotheses | Confirmed scope |
| Raw error dumps | Safe workaround if one exists |
| Personal frustration | Next update time |

## 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.
Original contribution: FACT update template: Facts, Action, Cadence, Tone, with paste-ready first, progress, and resolution messages.