An incident update is the message a customer reads when your site or app is not working. It needs to say what is wrong, who it affects, what you are doing and when they will hear again. Below is a plain template you can copy, with the four stages, what each update must contain, and example wording you can change.
The four stages: investigating, identified, monitoring, resolved
Most incidents move through the same four stages. You do not need to use every stage every time, but the order stays the same.
- Investigating. You know something is wrong and you are looking into it. You do not yet know the cause.
- Identified. You know the cause, or the part of the system at fault. You may not have a fix yet.
- Monitoring. A fix or workaround is in place. You are watching to check that the problem has gone.
- Resolved. The service is back to normal and you have stopped watching.
Use the stage name at the start of each update so readers can scan the page. A status page with a clear stage on every entry is easier to trust than one full of long paragraphs.
What each update must say: what is affected, what we know, when the next update comes
Every update, at every stage, needs three things.
What is affected. Name the service, feature or group of users in plain words. "Card payments are failing at checkout" is useful. "We are experiencing issues" is not. If you do not yet know the full reach, say that.
What we know. Give the facts you have today, and only those. If you think the cause is the database, say you think so and say what you have checked. Do not guess at a cause you cannot back up.
When the next update comes. Give a time, not a feeling. "Next update by 15:30" tells the reader when to look again. If there is no news by then, post anyway to say so. Then keep to the time you gave.
Example wording for each stage
Replace the bracketed parts with your own details.
Investigating
"We are investigating reports that [service] is slow or not loading for some users. We have not yet found the cause. Next update by [time]."
Identified
"We have found the cause of the problem with [service]. It is [plain cause, such as a failed deploy to the payments service]. We are working on a fix. Users who see [symptom] can [workaround, if one exists]. Next update by [time]."
Monitoring
"A fix for [service] has been applied. Requests are succeeding again. We are watching error rates for the next [period] to make sure the problem has not returned. Next update by [time], or sooner if anything changes."
Resolved
"The problem with [service] is resolved. It began at [start time] and ended at [end time]. [One plain sentence on impact, such as: Some users saw errors when saving changes.] We will publish a follow-up by [date] covering what we are changing to reduce the chance of a repeat."
None of these examples names a cause before it is known, and none says the problem will never happen again.
Words to avoid
Some words hide what happened or make readers less sure of you. Take them out.
- "Some users" with no sense of how many, or which ones. Say which users, or say you do not yet know.
- "Issues", "difficulties" and "a glitch". Say what broke.
- "Shortly" and "soon" as a time. Use a clock time.
- "Fixed" before the monitoring stage. You have applied a change. You have not yet shown that it works.
- "Unexpected" and "unforeseen". Readers do not need to hear that you were surprised.
- Blame on a supplier, a person or a team. Say what happened in your system. You can explain the wider cause later, once you have checked it.
- Hype words such as "amazing progress" or "we are thrilled". The reader wants facts.
Also avoid promises you cannot control, such as "this will not happen again". Say what you are changing instead.
Final update and follow-up
The resolved update closes the incident on the status page. Keep it short. Give the start and end times, the impact in one sentence, and the date of your follow-up.
The follow-up is where you explain the cause in more detail. Write it within a few days, while the details are fresh. Cover four points: what happened, why it happened, what you did to restore service, and what you are changing so the same cause is less likely to recur. Keep the tone the same as the updates: plain, calm and specific.
If you run a small team, one person should own the updates from start to finish, and a second person should read the wording before it goes out. That habit keeps messages consistent when the pressure is on.
You can post each of these stages from your AperioFlow status page, in the same place where your monitors report the problem. Start free at https://app.aperioflow.co.uk/#/signup. The free plan includes 10 monitors.