A status page is a single page, usually at status.yourcompany.com, where you show whether your service is healthy and post updates when it is not. When something breaks, it is the one place customers can check instead of opening a ticket or guessing. A good one turns a stressful outage into a calm, informed wait.
What a status page is for
It does three jobs. It answers the question are you down before support has to. It shows the current state of each part of your product at a glance. And it keeps a public record of past incidents and uptime, which is what prospects and procurement teams look for when they want to trust you.
Public or private
A public page is open to anyone and is the norm for customer-facing products. A private page sits behind a password or login and suits internal tools or early-stage products that are not ready to publish uptime to the world. You can start private and flip to public later. Either way, the page should only ever show what is actually true: a brand-new component with no data yet should say so, not a confident green.
What goes on it
- Components: the parts of your product (API, dashboard, payments) each with a current status.
- Uptime history: a 90-day track per component so visitors can see your record, not just the current minute.
- Incidents: a timeline of what happened, what you are doing, and when it resolved.
- Scheduled maintenance: planned work announced ahead of time so it does not read as an outage.
- Subscribe: let customers get incident updates by email or RSS so they do not have to keep refreshing.
Set one up in minutes
The quickest path: create the components that match how customers think about your product, attach an uptime monitor to each so status reflects real checks rather than a manual toggle, choose public or private, and publish. Add your own domain with automatic TLS when you want it on status.yourcompany.com. From there, the only ongoing work is posting a clear update when an incident happens, and even that can be drafted for you.
If your product depends on third parties (a cloud host, payments, email), map those dependencies too so an upstream outage shows on your page as what it is. See the guide on monitoring your dependencies for how that works.