Status page updates: what to write at each stage

During an outage people write too little, too late, or guess. Here is what to say at each stage, with an example update for each one.

The problem

During an outage, the people who use your service have one question: is it me, or is it you, and when will it work? A status page is where they look for the answer, and in the first minutes it usually says nothing at all, or "all systems operational" while the support inbox fills up.

Then the updates that do arrive go wrong in three familiar ways. Too little: "we are aware of an issue". Too late: the first post comes an hour in, after customers have announced the outage for you. Or a guess: "a database problem" in the first update, quietly corrected two posts later, which teaches readers not to believe the third.

Good updates are not about writing well under pressure. They follow a shape that is decided in advance, so whoever is on call can fill it in quickly.

What to write at each stage

Most outages go through four stages. Not every incident needs all four, but naming the stage at the start of each update tells a reader where things are at a glance.

Investigating

Post this as soon as you know something is wrong for customers, before you know why. Five minutes late is fine. An hour late is the outage your customers remember.

Say: what is affected, in the words customers use; what they see; since when, with the time zone; and when you will post next.

Do not say: the cause you suspect. You will often be wrong, and the correction costs more trust than the silence would have. Do not call it minor while you do not know how big it is.

Identified

Post when you know the cause, or at least the part that broke, and have a plan to fix it.

Say: the cause in one plain sentence, what you are doing about it, whether it is still affecting people, and the next update time.

Do not say: when it will be fixed, unless you are sure. "Next update by 15:00" is a promise you can keep. "Fixed by 15:00" often is not.

Monitoring

Post when the fix is in place and things look normal, but before you are confident it will stay that way.

Say: that it should be working again, from when, and what a customer should do if they were affected during the outage: retry, sign in again, check an order.

Do not say: resolved, yet. If it breaks again ten minutes later, a reopened incident looks far worse than a monitoring stage that lasted a little longer.

Resolved

Post when it has stayed fixed long enough for you to be sure. This is the update most people read later, often from a link someone shared, so it should stand on its own.

Say: what happened in plain words, from when to when, who was affected and how, what you did, and what you will change so it does not happen again. Apologise here, once.

How often, and the habits that keep trust

• Post on a schedule, even with no news. Every 30 minutes is a good rule during an outage. An update that says what you have ruled out and when you will post next is worth more than silence, because silence reads as nobody working on it.
• Give the next update time, and keep it. If 15:00 comes and you have nothing new, post that you have nothing new.
• Write every time with its time zone. Your customers are not all in your office. UTC is the safe default, and "14:02 UTC" cannot be misread the way "2pm" can.
• Name the parts customers know. "Checkout" and "the mobile app", not the name of the service or the cluster behind them.
• Never blame a supplier by name. Your customers chose you, not your suppliers, and naming one reads as passing the blame. "A service we depend on" is enough, and the problem is still yours to fix.
• Apologise once, at the end. One plain apology in the resolved update. Repeating it in every post fills the space where the information should be.

An update with no news still has a shape:

After the incident

The resolved update closes the outage. For anything that lasted long or affected many people, it should not be the last word. Within a few days, publish a short incident report that explains what happened to customers, why, and what changes, and link it from the incident on the status page. The guide to writing an incident report your customers will read has the shape and a full example.

How Upglory does it

On an Upglory status page, each update can carry one of four stages, investigating, identified, monitoring and resolved, or none. Picking a stage fills in an opening sentence for you to change into your own words. For a page row called Checkout they read:

• We are looking into a problem affecting Checkout.
• We have found the cause of the problem affecting Checkout and are working on a fix.
• A fix is in place for Checkout and we are watching it.
• Checkout is working normally again.

Each update can also promise the time of the next one, which the page and the update email both show.

People can subscribe to a page by email, and nothing is sent until they confirm the address. Then they get an email when an incident opens, with each update and when it ends, and before planned maintenance. Updates posted within 5 minutes of each other go out as one email, so a quick correction does not send a second one. Times in the emails are printed in the page's own time zone.

Your incident review and the AI written report stay with your team and never appear on the page. An incident can also be kept off the pages entirely. Updates can be posted from a script through the API too, with their stage.

The status pages overview shows a page and its emails, and the API reference has the call that posts an update.