01What a status page is actually for

The purpose is not to record history. It is to stop your customers wasting their afternoon.

When something breaks, every affected user independently forms the same hypothesis: it is probably me. They check their credentials, restart something, re-read their own code, and only then start looking for you. The gap between the outage starting and them learning it is not their fault is pure wasted effort, multiplied by however many customers you have. A status page exists to close that gap.

The second purpose is deflection, and it is the one that pays for the effort. Support volume during an incident is largely people asking whether you know. Answer it once, publicly, and most of those messages never get sent.

02Components, not one green light

A single site-wide indicator is close to useless. It is either green, which is uninformative, or red, which is alarming beyond what is usually true. Real failures are partial.

Break the page into the things a customer would recognise as separate, and be honest about which are affected. For a GPU platform that is roughly: the control panel, provisioning of new instances, running instances, storage, networking, billing, and support channels. Those fail independently and matter differently. A provisioning outage is an inconvenience for new customers and invisible to everyone else; running instances going down is an emergency for everyone.

Use more than two states. “Operational”, “degraded” and “outage” carry very different meanings, and degraded is where most incidents actually sit. Collapsing degraded into outage trains people to ignore red; collapsing it into operational is a lie with a short half-life.

03The first update matters most

The single most common mistake is waiting until you understand the problem. By the time you do, the trust damage is done, and the update you eventually post is competing with whatever your customers concluded in the silence.

Publish within minutes of confirming there is a real problem, before you know the cause. The first update needs only three things:

• What is affected, in customer terms. “New instances cannot be created” — not “the provisioning controller is returning 500s”.
• That you are working on it. One sentence. Not an apology paragraph.
• When you will next post. A specific time. This is the part people skip and it is the part that stops them refreshing.

Then meet that commitment even when there is nothing new. “Still investigating, next update at 15:30” is a useful message: it says the humans are still on it. Silence says nobody is.

Resist speculating about cause in early updates. Wrong guesses published under your own name are worse than no guess, and you will have to retract them while also fixing the thing.

04Uptime numbers and what they hide

Published uptime figures are reassuring and frequently meaningless, because the interesting part is the definition rather than the number.

Three questions decide whether a number means anything. What counts as down — total failure only, or degraded performance? Measured from where — your own network, or somewhere a customer actually is? And does scheduled maintenance count? A figure that excludes maintenance windows and only counts total outages can sit comfortably above 99.99% through a month customers found painful.

If you publish a number, publish the definition beside it. It is a smaller claim and a more credible one. And if you offer an SLA, the definition is the thing being negotiated — everything else is arithmetic.

05Let people follow it where they already are

Nobody visits a status page speculatively. They arrive during an incident, or they never arrive. That makes subscription the feature that determines whether the page does anything.

Offer email at minimum, and whatever chat tool your customers actually use. For a technical audience an RSS or webhook feed is worth more than it looks: it lets a customer wire your status into their own monitoring, which is a small piece of integration that quietly makes you harder to replace.

Two operational details. Host the page somewhere that does not share fate with the thing it reports on — a status page served from the infrastructure that is down is a recurring embarrassment. And keep the subscriber list separate from your marketing list. People who subscribed to outage notices did not opt into your newsletter, and conflating the two is the fastest way to lose both.

06Writing the update

Write for someone deciding whether to keep waiting or go find a workaround. That framing settles most wording questions.

Lead with impact, not architecture. Your customer does not have your system diagram and does not want it.

Say what still works. “Running instances are unaffected” is often the most valuable sentence in the update and is routinely omitted.

Give a workaround if one exists, even an ugly one.

Timestamp everything, with a timezone. Your customers are not all in your timezone; ours are not all in India.

Apologise once, at resolution. Apologising in every update reads as performance and displaces information.

Afterwards, write up what happened and what changes as a result. Not a formal document with a template — a few honest paragraphs. Customers are considerably more forgiving of a company that explains an outage plainly than of one that quietly marks it resolved and never mentions it again. The write-up is also the only artefact that makes the incident worth anything internally.

Our own current position, stated plainly: we are small enough that incidents reach customers by email from a person rather than through a status page, and honest enough to say that is a stopgap rather than a policy. If you are evaluating us and want to know how we would handle an outage affecting you, ask at contact@vijaycloud.com and you will get a straight answer rather than a link to a dashboard.