# 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.
Author: fajita-editorial
Published: 2026-07-17
Updated: 2026-07-17
Last reviewed: 2026-07-17
Version: 1
Canonical: https://fajita.io/blog/what-belongs-on-status-page
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

1. Current overall state in plain language
2. A short list of customer-visible components
3. Active incidents with timestamps and updates
4. Scheduled maintenance with start and end windows
5. Recent history so visitors can see patterns
6. 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 |
| Email | 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.
Original contribution: Customer-Visible Component Rule: if a customer cannot name the impact in their own words, it is not a public component.