A status page customers believe: what to publish and what to skip

Customers stop reading a status page the first time it says "All systems operational" while they are staring at an error. After that it is decoration, and they go back to opening tickets. Everything below is about avoiding that first lie.

The page has one job

A status page answers one question: "is it me or is it you?" It does not need to explain your architecture, apologise at length or show off your uptime. If a visitor can answer that question in five seconds, the page worked, and most of the tickets that would have followed never get written.

Two properties make that answer believable: it is current and it is specific. Most advice about wording is really advice about those two.

Let the page follow the checks, not the people

A page that someone has to remember to update is wrong exactly when it matters. During an incident the people who could update it are busy fixing the problem. The first update arrives late, the last one arrives after the fix has been quietly live for an hour, and in between the page says whatever it said before things broke.

The fix is to drive the component status from the same checks that page your team. Then "degraded" appears when your monitoring sees it, not when somebody gets a free minute. Hesklo status pages work this way: the page reads live state from the same monitors that drive your alerts. Humans still write the explanation, but they do not have to be the source of truth for the colour.

That only holds if the underlying check is trustworthy. A monitor that flaps on single timeouts will paint your public page red for a minute at a time and teach customers to ignore it. The same confirmation logic that keeps pages quiet keeps the status page honest.

What to publish

Components customers recognise

List things by what customers do, not by what you run. "Checkout", "Login", "API" and "Webhook delivery" are components. "payments-svc-eu-2" is not. Customers cannot judge whether an internal service name affects them, so they will assume the worst or ignore it.

Keep the list short. Five to ten components is plenty. Each one you add is another place the page can be wrong, and another row to read during an outage. Publishing is opt-in per monitor in Hesklo, so internal infrastructure stays private by default. That is the right default: expose a monitor only when a customer could say "that is the thing I use".

The impact, in the customer's words

Compare these two updates:

We are investigating elevated error rates on a backend dependency.

Some customers cannot log in. Already signed-in sessions are unaffected. We are investigating.

The second one lets a reader decide whether to wait or work around the problem. Say who is affected, what they see and what still works. If you do not know yet, say that too: "We do not yet know how many customers are affected" is more believable than a confident guess.

A time and a next-update promise

Put a timestamp on every update, with a timezone. End each one with when the next update will come, such as "Next update by 14:30 UTC", and then keep to it. If nothing has changed by then, post "no change, still investigating". Silence reads as abandonment, and a promised update that arrives is worth more than a vague "soon".

Planned maintenance, ahead of time

Announce planned work before it starts, with the window and what customers will notice. A monitor paused for a maintenance window should not look like an outage, and an announced window should not look like an unexplained gap.

What to leave out

Guesses about root cause. "Looks like a database problem" becomes wrong half an hour later, and you will have to retract it in public. Describe symptoms until you are sure of the cause.
Blame. Naming a vendor, a deploy or a person in a live update helps nobody. Customers care about their impact, not your supply chain.
Internal jargon and hostnames. If a customer cannot act on a word, cut it.
Security details. Do not describe the exact mechanism of an attack or a vulnerability while it is open. Say what customers should do, and publish a fuller write-up later if appropriate.
Vanity numbers. A "99.99% uptime" badge next to a red component invites an argument you will lose.
Optimism. Do not write "should be resolved shortly" unless you can say what "shortly" is. An ETA you miss costs more trust than no ETA.

Use the stages, and make them boring

A simple, fixed vocabulary is easier to trust than clever prose. A common sequence is:

Investigating. We know something is wrong. We do not know why.
Identified. We know the cause and are working on a fix.
Monitoring. A fix is in place and we are watching it.
Resolved. Everything has been healthy for a stated period.

Do not skip straight to "resolved" the moment a check goes green. Services often recover, relapse and recover again, especially after a restart or a cache flush. Waiting through a short "monitoring" stage costs you ten minutes of caution and saves you a second, embarrassing "we are investigating again".

Be accurate about when it started

Customers know when they first saw errors. If your page says the incident began at 14:10 and they were failing at 13:50, they conclude you either did not notice or are shaving the number. Where your detection was slower than the real start, say so: "Errors began at about 13:50 UTC; we were alerted at 14:10." It is an uncomfortable sentence and it is the one that makes the rest believable.

This is also a reason to keep monitoring honest about timing. The history of checks gives you a record of when the first failure was seen, which is better than reconstructing it from memory afterwards.

An update template

[Stage] - [Component]: [what customers experience]

Impact: [who is affected, what still works]
Started: [time, timezone]
What we are doing: [one sentence, no speculation]
Next update: [time, timezone]

A filled-in example:

Investigating - API: Requests are failing with 502 errors

Impact: Some API requests fail. The dashboard and webhooks are unaffected.
Started: 13:50 UTC
What we are doing: We are looking at recent changes and checking capacity.
Next update: 14:30 UTC

Checklist

Component colours come from monitors, not from someone's memory.
Components are named after what customers do, and there are fewer than ten.
Internal-only monitors are not published.
Every update has a time, a stage, the impact and a next-update time.
No root-cause guesses, no blame, no jargon.
"Resolved" waits for a short monitoring period.
The start time reflects when customers were first affected.
Your page lives somewhere customers will find it, ideally on your own domain such as status.your-domain.com, and is linked from your app and support footer.

None of this requires special tooling. A page that is accurate, specific and a little dull will outperform a polished one that is late. If you do want one wired to your monitors, see status pages and pricing for which plans include them.