What Should Your Status Page Say During an Outage?

What should your status page say in the first ten minutes?

That you know, what is affected in the customer's language, and when you will speak again. Three sentences is enough. You do not need the cause, the fix, or an apology paragraph. You need to convert a room full of people guessing into a room full of people waiting.

Most teams get this backwards. They wait until they understand the problem before they say anything, which means the first twenty minutes of an incident are the loudest twenty minutes on your support channel and the quietest on your status page.

I think of the status page as a marketing surface, not an engineering one. It is read by customers, by prospects mid evaluation, and by whoever is about to renew. What it says during a bad hour does more for retention than most campaigns do in a quarter.

Why is silence the most expensive option?

Because customers fill silence with the worst available explanation. If your page says everything is operational while their app is not loading, they conclude either that you do not know or that you are hiding it. Both are worse than the outage itself, and both outlast it.

There is also a practical cost. Every minute you do not publish is a minute your support inbox absorbs the same question from a hundred people. A single accurate line on a status page is the highest leverage support ticket deflection you will ever write, and it costs nothing to send.

The instinct to wait is understandable. Nobody wants to publish something that turns out to be wrong. But an update that says we are investigating reports of slow loading is never wrong, because it describes what you are doing rather than what is broken. You can always say what you are doing.

What does a customer actually need from an incident update?

Four things, in this order. Whether they are affected. What they cannot do right now. What they should do in the meantime. And when the next update will arrive. Everything else is optional, and most of it is for you rather than for them.

The one people forget is the third. If a customer cannot export a report, telling them the export service is degraded is half an answer. Telling them the export service is degraded and that the data is intact and will be available when it recovers is a complete one. The second version prevents a support ticket and a small panic.

The fourth matters more than it looks. A stated next update time is a promise you can keep even when you cannot fix anything. If you say the next update is in thirty minutes and you post in thirty minutes to say there is no change, you have demonstrated something about how you operate. People remember that.

How much technical detail is too much?

Any detail that does not change what the reader does. Your customers do not need to know which service is failing health checks. They need to know whether to tell their own customers something. Write for the person who has to answer for you inside their company.

This is where engineering led status pages go wrong. Precision about internals reads as transparency to the person writing it and as noise to the person reading it. Worse, technical specificity in the first hour is often wrong, and a corrected technical claim is harder to walk back than a vague one was to publish.

The version I like describes symptoms and scope. Which features, which regions, which plan, roughly what proportion of requests. That is enough for a customer to decide whether to wait or to work around it, and it does not commit you to a diagnosis you have not confirmed.

The instinct here is the same one I apply to any page meant to convince a wary reader. Say the thing that changes the decision and stop. I made the same argument about evidence in what proof a skeptical B2B buyer looks for first, and an incident is just a moment where the stakes are higher.

Who should write the update, and who should approve it?

One named person writes, and the approval step is decided before the incident, not during it. If your process requires a legal review of a status update, you do not have a status page. You have a press release process with a clock on it.

The workable version I have seen is a short list of pre approved phrasings that anyone on call can publish without asking, plus an escalation rule for anything involving data. That way the first update goes out in minutes and the sensitive judgement calls still get the attention they deserve.

Marketing should own the template and engineering should own the trigger. When marketing owns the trigger, updates are late and polished. When engineering owns the template, updates are fast and unreadable. Splitting it gives you fast and readable, which is the only combination that helps.

What should you never say during an outage?

Three things. Do not blame a vendor by name while you are still guessing. Do not promise a resolution time you have not earned. And do not describe the impact as minimal unless you can say who it is minimal for, because to the customer who cannot work it is total.

Naming a vendor mid incident is the one I see most often and it is the one that ages worst. If you are wrong you have publicly accused a partner. If you are right you have told your customers that your reliability is somebody else's decision, which is not the takeaway you want during a renewal conversation.

The resolution time promise is the second trap. An estimate given under pressure and missed does more damage than no estimate at all. Give a next update time instead. You control that completely, and keeping it is the thing being measured.

When does an incident deserve a written post mortem?

When it damaged trust, not when it was technically interesting. A short outage that nobody noticed does not need a public write up. A two hour failure during the working day, anything involving data, and anything that repeats within a quarter all do.

What makes a post mortem worth publishing is the change it names. Readers are not looking for an explanation of the failure. They are looking for evidence that the same failure is now less likely. A page that describes root cause in detail and concludes with we will continue to monitor has told them nothing.

The useful ones say what specifically changed: a check that did not exist, a limit that was raised, an alert that now pages a human. That is a claim a customer can hold you to, and being willing to make it is most of the value.

It also feeds back into the product. The complaints an incident surfaces are unusually honest, in the same way the answers are when you ask people why they left. That is why I treat both as research, and why I care about the churn interview questions that actually change a roadmap.

How does incident communication affect a deal in progress?

More than most founders expect. A buyer evaluating you will read your status history, because it is one of the few public records of how you behave when things go wrong. An empty history reads as either reliability or concealment, and they cannot tell which.

A history full of honest, well written incidents reads better than an empty one. It says you have a process, you tell people things, and you do not disappear. In a category where every vendor's marketing site says the same words about reliability, that record is one of the few differentiated pieces of evidence you own.

I have watched this cut both ways across six years and seventy plus projects. The clients whose incident pages read like a human wrote them get the benefit of the doubt. The ones with a green dashboard and a support queue full of confused customers spend that goodwill fast.

The same logic applies to the first weeks after someone signs, when every small experience is being used to decide whether this was a good idea. That is the argument I made in what a lifecycle email should do in week one, and an incident in that window carries far more weight than the same incident a year later.

What should you do next?

Write the first update now, before you need it. Three sentences: what you are seeing, what it affects in customer language, and when you will speak again. Save it where the person on call can find it at two in the morning without asking anyone for permission.

Then look at your last incident and ask whether a prospect reading that page would have felt informed or managed. If the answer is managed, rewrite it. The archive is public and it is being read by exactly the people you are trying to win.

If you want help turning your status page and incident writing into something that actually supports the sale rather than undermining it, reach out. Let's chat.