Status Page Best Practices — What a Great Public Status Page Looks Like

A public status page is the cheapest trust infrastructure you will ever ship. When something breaks, every customer asks the same two questions — is it just me? and do they know? — and a good status page answers both before anyone opens a support ticket. A bad one does the opposite: a wall of green checkmarks during a visible outage teaches customers that your status page lies, and they never check it again.

Here's what separates the status pages people actually trust from the ones that exist purely so a sales deck can say "we have one."

Component granularity: not one dot, not fifty

The single most common design mistake is granularity at the wrong altitude.

• One global "All Systems Operational" dot is useless. If your API is down but your marketing site is fine, a single indicator forces you to either lie (green) or panic everyone (red).
• Fifty microservice-level components is just as bad. Customers don't know or care what auth-service-worker-2 is. Internal topology belongs on your internal dashboard.

The right granularity is the customer's mental model of your product: the surfaces they touch and would describe in a support ticket. For a typical SaaS that's something like:

• Web application / dashboard
• API
• Background processing (webhooks, exports, emails)
• Status page & notifications (yes — host it separately from your main infrastructure, or it goes down with everything else)

Five to ten components is the sweet spot for most products. Each component should map to a real monitor underneath it, not to a human toggling a dropdown — more on that below.

Honest uptime history beats a perfect one

Show real historical uptime per component — 90 days is the widely-adopted convention. And resist the temptation to scrub it.

A page showing 99.97% with two honest incidents in the last quarter is more credible than one showing 100.00%, because everyone who has operated software knows 100.00% over a quarter usually means the page isn't wired to anything. Honest history does three things:

• It proves the page reflects reality, so people trust it during the next incident.
• It gives sales and procurement a real answer to "what's your uptime?" without a spreadsheet exercise.
• It keeps you honest internally — a visible dip is a stronger nudge to fix root causes than a buried metric.

The strongest version of this is a status page driven directly by your monitoring, so a failed check flips the component automatically. Manual-only status pages drift toward fiction, because updating them during an incident is exactly the moment nobody has spare hands. (If you're still designing the checks themselves, our guide to uptime monitoring best practices covers intervals, locations and confirmation probes.)

Incident updates: cadence beats prose

During an incident, the status page is your broadcast channel. The rules that matter:

• Acknowledge fast. An "Investigating" post within minutes — even one that says almost nothing — beats a polished paragraph an hour later. Silence is what generates tickets.
• Commit to a cadence and keep it. "Next update in 30 minutes" is a promise; keep it even if the update is "no change, still working." A stale two-hour-old update reads as abandoned.
• Move through explicit stages — Investigating → Identified → Monitoring → Resolved — so readers can see progress without parsing prose.
• Timestamp everything and leave the full history visible after resolution. The trail is part of the trust.

Writing the actual updates is a skill of its own — what to include, what to omit, how to sound calm without over-promising. We've published copy-paste incident communication templates for every stage, so nobody is composing from a blank page at 3 a.m.

Subscriber notifications: let customers opt into the truth

A status page people have to remember to check only does half the job. Let them subscribe — email at minimum; Slack, RSS or webhooks if your audience is technical. Subscriptions flip the dynamic: instead of a thousand customers polling your support inbox, your status page pushes one message to everyone who cares.

Two details worth getting right:

• Notify on the first update, not just resolution. The whole value is "they already know."
• Don't spam. Component-level subscriptions let an API-only customer skip news about your marketing site.

Custom domain and branding

status.yourproduct.com on your own domain, with your logo and colors, matters more than it seems:

• Customers verify they're looking at your page, not a generic hosted URL a phisher could imitate.
• Procurement and enterprise security reviews routinely ask for a status page URL; a branded one reads as operational maturity.
• For agencies running client sites, white-label status pages are table stakes — the client should see their own brand, not the monitoring vendor's.

One infrastructure note: serve the status page from infrastructure that is not behind the same load balancer, DNS, or cloud account as your product. A status page that shares your product's failure domain is a screen door on a submarine.

When a status page saves your support inbox

The economics are simple: during an incident, support volume tracks uncertainty, not severity. A visible, updating status page converts "is it just me? do they know? should I migrate?" into a single glance. Teams consistently report the same pattern — the moment the incident is acknowledged publicly, the ticket flood slows to a trickle, and the tickets that do arrive start with "I saw the status page, just adding context" instead of anger.

That's also why the link placement matters: put the status page in your app's error states, your support contact page, and your email footer. A great status page nobody can find saves nothing.

Anti-patterns: the always-green page nobody trusts

A quick hall of shame — if your page does any of these, fix that before polishing anything else:

• The eternal green wall. Manually curated, updated only when someone remembers, green during outages your customers can see with their own eyes. Worse than no page.
• Component theater. Components exist but nothing flips them automatically, so every incident is "Degraded performance" on "Other."
• The euphemism engine. "Some users may be experiencing intermittent difficulties" for a full outage. Customers can tell, and they remember.
• Retroactive incident history. Deleting or editing past incidents. The history is the credibility.
• Hosted on your own stack. The status page 404s at exactly the moment it matters.

The checklist

• 5–10 components matching the customer's mental model
• Components driven by real monitors, not manual toggles
• 90-day honest uptime history, never scrubbed
• Investigating → Identified → Monitoring → Resolved workflow with a kept cadence
• Email/webhook subscriptions, notified from the first update
• Custom domain + your branding (white-label if you serve clients)
• Hosted off your main infrastructure
• Linked from error states, support pages, and email footers

Every CompleteStatus plan — including Free — includes a public status page wired directly to your monitors, with incident workflows, subscriber notifications, and honest uptime history built in; Business and Agency add white-label branding for client-facing pages. It's one piece of the consolidated monitoring stack, not another subscription. See everything it covers on the features page, check any site right now with the free uptime test, and create your status page free — the free tier allows commercial use.