How to write an incident update customers can follow
Published 19 September 2026
An incident update is read by somebody who depends on your product, has just seen it misbehave, and has to decide whether to wait, work around it or warn their own customers. Write every update for that person.
What every update should answer
- What is affected, in the words a customer uses: checkout, sign-in, email delivery.
- What they will notice, such as errors, slow pages or messages arriving late.
- What you are doing about it right now, in one sentence.
- When the next update will come.
Leave the cause out until you are sure of it. A guess in the first update turns into a correction in the second, and people remember the correction.
Investigating
Post this as soon as you know customers are affected, before you know why. Its job is to confirm the problem is real and that somebody is on it. Keep it to impact.
"Some customers are seeing an error when they pay at checkout. We are investigating and will post again by 14:30 UTC."
Identified
You know the cause and you are working on the fix. Say what you found in plain terms and what happens next. Readers need enough to judge how long this will last, and they rarely need the internals.
"We have found the cause: a change to our payment service released at 13:50 UTC. We are rolling it back now and expect checkout to recover within 20 minutes."
Monitoring
A fix is in place and you are watching it hold. This is the update that tells people what to do about anything that failed while the incident was open.
"The rollback is complete and checkout is working again. We are watching error rates to make sure the fix holds. If a payment failed between 13:52 and 14:41 UTC, please place the order again."
Resolved
It is over. Give the time it ended, what was affected while it lasted, and whether a fuller account is coming.
"Checkout has worked normally since 14:41 UTC. Between 13:52 and 14:41 UTC some payments failed, and those orders were not placed. We will publish a postmortem here within five working days."
How often to post
Post when something changes, and post when nothing has changed for a while. Silence during an outage reads as nobody being on it. Naming the time of the next update, and keeping to it, stops people asking whether there is news.
Corrections, templates and postmortems
On InBrief, updates are append-only: a published update stays part of the record. To correct a detail, post another update and tick Publish silently, so subscribers are not emailed about a typo. If the same kind of incident comes round more than once, keep a template for its first update and the first post takes seconds to send.
Once the incident is resolved, the postmortem goes under it on your status page, written in Markdown. The first time you publish it, subscribers are told.