Buyers read your outage history

A status page gets built because something will go wrong. That is its whole brief. Then it turns into the page your most sceptical buyer opens first, ahead of the pricing and the case studies, and they do not read today's entry. They scroll back.

What they are looking for is not a clean record. They are looking at how you wrote it down. Whether the language got vaguer as the hours went on. Whether you said what actually broke. Whether the last note explained anything or simply announced that the incident was resolved. That is a judgement about your company, formed on a page most hosting companies have never had written, edited or designed by anyone in particular.

What to put on a status page during an outage

Four things, in this order, because people stop reading.

What is broken, in the customer's words rather than the system's. "Customers cannot log in to the control panel" tells someone whether to keep working. "Degraded performance in the auth tier" does not.

Who is affected. A customer who cannot tell whether the problem is them or you will open a ticket, and your support queue is now part of the incident.

What you are doing about it, at the length of one sentence. Nobody needs the architecture.

When you will next post, even if you expect to have nothing new. The next-update time is the most useful line on the page, because it is the part that lets someone put their phone down and go back to work. It is also the promise most status pages break first.

"All systems operational" is a claim, and claims get checked

Green lights are a factual statement about your service, published by you, to an audience that has its own monitoring. When your dashboard says everything is fine while a customer is watching requests fail, you have not avoided an incident. You have told them your instrumentation cannot see what they experience, which is a worse thing to learn about a supplier than an outage is.

Nobody technical believes in a clean record. They believe in a well-written one.

This is the part that gets mistaken for a communications problem. It is a product decision. If the status page is wired to a check that pings your homepage, it will stay green through most of the failures your customers actually care about.

The resolved note is the one buyers read

By the time somebody is evaluating you as a supplier, the incident is months old and only the final note survives. "This incident has been resolved" survives as nothing. A sentence that says what broke, what you changed so it does not break the same way, and what you are still not sure about, survives as evidence that someone was paying attention.

Admitting the thing you have not fixed yet is the part that feels dangerous and is not. A note claiming full understanding of a complex failure within the hour reads as a company that would rather be reassuring than accurate. The people reading it run infrastructure themselves. They have written those notes. They know what an hour buys.

The plain-language duty is already written down

Hosting and cloud companies inside the scope of the EU's NIS2 directive work to a clock: an early warning to the regulator within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within a month. The same directive expects entities to tell the recipients of their service, without undue delay and in easily understood language, about measures or remedies they can apply.

So "easily understood language" is not a nicety somebody in marketing added. If you sell into the EU, that note will be written under time pressure and read by a regulator and your customers at once. The only thing left to decide is whether it was drafted in advance by someone who can write, or at three in the morning by whoever happened to be awake.

Why this sits with design and not operations

Our hosting work starts from a plain view: technical buyers punish decoration and reward anything they can check themselves. When we rebuilt Servebolt's website, the persuasive part was not an adjective about speed, it was benchmark results a buyer could run again. An incident history works the same way. It is the one place on your site where you describe yourself at your worst, which is exactly why it carries more weight than the homepage does.

We have argued before that hosting churn is not a price problem, that customers leave over the product they actually touch. Incidents are a version of the same thing. The outage is the event. The note is the product.

Write it in daylight

None of this is an engineering project. It is four short templates, a vocabulary everyone has agreed on, a named person with the authority to publish without calling a meeting, and a status check that measures what customers do rather than whether the server answers. An afternoon of work, most of it spent arguing about words.

The hard part is deciding, calmly and well in advance, what you will say when you do not yet know what is wrong. Companies that have had that argument once sound different for years afterwards.