What is a status page and what belongs on one

What goes on a status page

A status page has three layers, and most of the value is in the first two.

The top layer is the current state of each component you list. Components are the pieces a customer can tell apart: the website, the API, the dashboard, logins, the payment flow, a mobile app backend. The state is usually a short ladder rather than a binary, so you can say "degraded" for a service that is slow but answering, instead of choosing between a green tick that is wrong and a red cross that is worse.

The middle layer is the incident feed. Each incident is a short entry with a start time, a plain description of what customers will notice, and updates appended as the situation changes, ending with a resolution note. Past incidents stay visible, which is what turns the page into a record rather than a light switch.

The bottom layer is history: uptime over the last 30 or 90 days per component. It is the least urgent part and the one that gets read most often by people evaluating you.

Public or private

A public status page is open to anyone with the link, and it is the right choice when your customers are the general public or when you publish an SLA. It also absorbs traffic during an outage from people who are not customers at all.

A private status page is restricted to signed-in customers or to an internal audience. Teams use it when the component list would expose internal architecture, when incidents involve named enterprise customers, or when the page covers internal systems that no outsider should be enumerating. The tradeoff is that anyone who cannot reach it will contact support instead.

Whichever you choose, host the page away from the infrastructure it reports on. A status page that goes down with the service is worse than no status page at all, because its silence during an outage is read as a claim that nothing is wrong.

Writing an incident

An incident entry is written for a customer, not for the engineers fixing it. That means the symptom first, the cause later if at all.

1. Open the incident as soon as you have confirmed the problem, even if you do not yet know the cause. "We are investigating reports of errors on checkout" posted at minute two is worth more than a complete explanation at minute ninety.
2. Say what a customer will see and what they can do about it, including a workaround if there is one.
3. Update on a rhythm you state up front, and post the update even when it is "no change yet". Silence reads as abandonment.
4. Close with a resolution time and, for anything long or severe, a short note on what happened afterwards.

Match the component state to the incident. An open incident on a component still showing green is the fastest way to lose trust in the page. If the underlying failure is a server refusing requests, 503 Service Unavailable is the response your customers are most likely quoting at you.

Scheduled maintenance

Planned work belongs on the same page, announced ahead of time with a window and an expected impact. Posting it in advance turns an outage into an appointment: customers who saw the notice do not file tickets, and the ones who did not can at least find the explanation while it is happening.

Distinguish maintenance from an incident visually and in the record, and keep the announced window honest. A maintenance window that regularly overruns trains people to ignore the next one.

Why it reduces support load

During an outage the support queue fills with one question asked many times. A status page answers it once, at an address you can point at from your support autoresponder, your app's error state and your social accounts. That converts an hour of repetitive triage into a link.

The secondary effect is on trust. Publishing incidents costs less than it appears to, because the customers who noticed the outage already know it happened. What they are judging is whether you told them.

Where the status comes from

A status page is only as good as the monitoring behind it. If a human has to notice an outage before the page changes, the page will always be behind the customers reading it, so the component states should be driven by checks that run continuously from outside your network. HostTracker hosts status pages fed by its own monitoring, which checks from 300+ checkpoints in 158 cities across 13 monitor types, so a component's state follows the check results rather than someone remembering to update it. For what those checks look like, see the HTTP check guide, and the rest of the monitoring concepts section for the surrounding terms.