How to Create a Status Page

A status page is only worth having if it updates itself during an incident and customers can find it when they need it. These steps build one that is driven by real monitors from the start, with enough human context to reduce support noise.

1. 1

   Decide which components to show

   List the parts of your product a customer would recognize and care about separately — the main site or app, the API if others integrate with it, checkout or billing if it fails independently, and any critical background service customers notice when it stops. Keep the list short and meaningful; three to six recognizable components beat twenty internal labels nobody outside your team understands.

2. 2

   Attach each component to a real monitor

   Connect each component on the page to the monitor already checking it — the same outside-in check or heartbeat that watches your site day to day. This is what makes the page update itself: the component goes red when the underlying check fails, and green again when it recovers, with no manual step in between. If a component has no monitor behind it, either add one or leave it off the public page.

3. 3

   Publish and link it from where people will look

   Put the status page link somewhere it will actually be found during an incident — your site footer, docs, support auto-reply, onboarding emails, and API documentation are common places. A status page that is technically live but linked nowhere does not save support tickets. If customers have contracts or SLAs, make sure the page is the place you will reference during an outage.

After it's live

During a real incident, post a short update as soon as you know something is wrong, even before you know the cause — "we are aware and investigating" beats silence. Update again when you have more information, and post a resolution note when it is fixed. The automatic component status handles "up or down"; a short human note handles impact, scope, workaround, and next update time. Both matter during an incident.

What to add second

Once the page is live and correctly wired to real monitors, add the pieces that reduce repeated questions: an uptime history badge, RSS or email subscriptions, and a short incident template your team can reuse under pressure. If the underlying monitors include TLS or domain-expiry checks, decide whether those deserve customer-facing components or whether they are better represented as part of the main site status — a certificate about to expire is a real risk, but it may not need its own public line.

Common mistakes to avoid

Listing every internal component. A page with a dozen components no customer recognizes is harder to scan at a glance than one with three or four that actually matter to them — save the detailed breakdown for an internal-only view if your team wants one.

Wiring it to nothing. A status page not connected to a real monitor is just a static page someone has to remember to update, which fails at exactly the moment people are busiest. The source of truth should be the monitor already detecting the problem.

Publishing it and linking it nowhere. As in step 3, a status page that is live but not linked from your site, docs, or support flow will not be found by anyone during the moment it matters. Test discoverability the same way you test alerts: ask where a customer would look first.