Status Page Guide: Build One Customers Actually Use

What this guide covers

A status page is the public face of your reliability. Done well, it deflects support tickets during an incident and builds trust the rest of the time. This guide covers which components to list, how to name them in language customers recognize, what to keep off the public page, and how to keep every component honest by backing it with a real check.

• Translate internal systems into the services customers recognize.
• A clear public page deflects tickets during an incident.
• Fewer, accurate components beat an exhaustive dependency map.

Choosing and naming components

List the services a customer would name if you asked them what they use: Website, API, Dashboard, Checkout, Email delivery. Each component should map to something the customer can act on — retry, wait, or contact support — not to an internal subsystem. If two internal services always fail together from the customer's point of view, represent them as one component.

• Name components in customer language, not internal service names.
• One component per thing a customer would independently notice.
• Keep the list short enough to scan in a few seconds.

Public vs private: what to expose

Not every check belongs on the public page. Internal queues, cron jobs, and third-party dependencies are essential to monitor but usually confuse customers. Keep them as private checks that alert your team, and surface only the customer-facing components publicly. The test: would this component's status change what a customer does in the next five minutes? If not, keep it internal.

Keeping the page honest

A status page that is updated by hand lags reality and, worse, gets forgotten during the exact incident it exists for. Back each public component with a live check so its state reflects measured availability automatically. Reserve manual updates for the incident narrative — what is affected, what you are doing, and when the next update lands — while the component indicators track the machines.

How Sandglass supports the practice

In Sandglass, attach a check to each public component so its state is measured, not toggled by hand. Group the checks that back customer-facing services and expose only those on the public page; keep noisy internal dependencies private and route their alerts to your team channel. When a backing check fails, the component reflects it automatically, so the page tells the truth without anyone updating it under pressure.

• Back the practices here with HTTP, ping, TCP, content, SSL certificate, and heartbeat checks.
• Route incidents to email, Slack webhook channels, and generic webhooks so the right people respond fast.
• Use a public status page to keep customers informed while the team works the incident.

Common mistakes to avoid

A status page becomes noise when it mirrors every internal dependency. Customers do not know or care about "queue-worker-3" — they care whether login, checkout, and the API work. Listing forty internal components buries the three that matter, and a page nobody trusts is worse than no page at all.