Status Page Best Practices: What to Show (and What to Hide)

Every status page makes an implicit promise: when things break, this page will tell you the truth. Users only need to catch it lying once — a green page during a visible outage — to stop checking it forever. These practices are about keeping that promise.

Structure: components users recognize

Organize monitors into components named after what users experience, not your architecture. "Website", "API", "Dashboard", "Notifications" — not "k8s-prod-cluster" or "edge-lb-2". A visitor should be able to answer "is the thing I use broken?" in two seconds.

• Keep it to 3–8 components. One monolithic "App" hides information; twenty micro-components bury it.
• Order by importance: the thing most users touch goes first.
• If you serve multiple regions and they fail independently, split by region — otherwise don't.

Show real uptime, including the bad months

Publish uptime percentages and history, and let them be imperfect. A page showing 99.7% with two documented incidents reads as honest; a page showing a flat 100% reads as either unmonitored or edited. Counter-intuitively, visible recovery from incidents builds more trust than a spotless record.

Incident hygiene

Open incidents fast, even with no answers

The first update's job is not to explain — it's to acknowledge. "We're investigating elevated errors on the API" posted three minutes in beats a detailed post-mortem posted after users gave up. Users refresh the status page during outages; silence there is loud.

Update on a cadence, then say the cadence

"Next update in 30 minutes" kills the refresh anxiety. And post the resolution: an incident that ends without a "resolved" update looks abandoned, not fixed. (Copy-paste wording in the templates guide.)

Never delete history

Incident history is your track record. Deleting embarrassing incidents is the fastest way to make the page worthless — users notice, and screenshots outlive edits.

Use maintenance windows for planned work

Planned downtime shown as an outage trains users to ignore red. Announce maintenance ahead of time with a window and scope; your uptime stats stay meaningful and nobody escalates a deploy as an incident.

Make it findable and independent

• Own domain: status.yourdomain.com is guessable when your main site is dead. Use a custom domain.
• Separate infrastructure: the page must not share hosting, DNS, or CDN fate with what it monitors. This is the strongest argument for a hosted status page over self-hosting.
• Footer link everywhere: site footer, docs, support signatures, error pages.
• Subscriptions: offer email or RSS so users get pushed updates instead of polling.

The mistakes that destroy credibility

• The eternally green page. If your Twitter says outage and your status page says operational, the page is now negative marketing.
• Manual-only status. Pages updated by hand during incidents are updated late or never. Drive state from real uptime monitoring.
• Jargon incidents. "Elevated 5xx from the ingress layer" means nothing to customers. Say what's broken from their side and what they can/can't do.
• Blame-forwarding. "Our provider is down" is context, not an update. It's still your outage to communicate.

Checklist

All of the above is supported on QUICCSTATUS's free status page — components, monitors, incidents, maintenance windows, custom domains, and subscriptions included.