What Should Go on a Public Status Page?
A status page earns trust when it shows customer-visible systems, current state, active incidents, maintenance, and a way to get updates. Internal service names and vanity metrics usually do not belong.
A public status page should answer three questions quickly: is anything wrong, what is affected, and when will you speak again. Everything else is optional. This guide defines what belongs, what does not, and a simple rule for naming components.
The Customer-Visible Component Rule
If a customer cannot name the impact in their own words, it is not a public component. "Checkout," "API," "Dashboard," and "Status notifications" pass the test. "redis-prod-3" and "worker-pool-b" fail it.
What belongs on the page
- Current overall state in plain language
- A short list of customer-visible components
- Active incidents with timestamps and updates
- Scheduled maintenance with start and end windows
- Recent history so visitors can see patterns
- A subscribe path with verified email preferences when you offer one
What usually does not belong
- Internal hostnames and ticket ids
- Raw response-time charts you will not explain during an outage
- Marketing claims or pricing CTAs above the fold
- Fake uptime precision that your check interval cannot support
- Every microservice in the company
Naming components
| Weak name | Stronger name | Why |
|---|---|---|
| Backend | API | Customers call it the API |
| Frontend | Web app | Matches how users navigate |
| Jobs | Report generation | Names the outcome |
| Notification delivery | Scope is clearer |
Maintenance without surprise
Publish maintenance before it starts. State customer impact honestly. If a window slips, update the page. Silence during a planned window looks like an unplanned outage. See scheduled maintenance and Create maintenance.
Subscribers
If you offer email updates, use double opt-in and preference controls. Do not surprise people with marketing. Product details: Double opt-in.
Readiness check
Before you call the page ready, walk the status-page readiness checklist. Ownership, components, monitor mapping, incident process, and a test publish matter more than theme polish.
History and honesty
Show enough history that a customer can see whether today’s incident is rare. Do not invent decimal places your monitors cannot support. If you exclude maintenance from uptime math, say so near the number. Related: How to Calculate Uptime Correctly.
Keep it current
A stale green page during a known outage is worse than no page. Assign who updates it, practice one drill, and link incident writing guidance from How to Write a Useful Incident Update.
If nobody owns the page, it will rot. Ownership is a component of the product experience, even if customers never see the owner’s name.
Plain-text version · Status Pages
Was this useful?