A status page is a public web page that shows the real-time operational status of a website, app, or API, including current incidents, component health, and historical uptime. It tells your users whether a problem is on your side, so they stop filing tickets and stop guessing during an outage. Instead of one thread per customer, you post once, and everyone reads the same honest update.
The idea is simple, but it does real work. When your service is down, people notice fast and they all want the same answer: is it you, or is it me? A status page answers that in one place, in public, so your support queue does not fill up with the same question a hundred times over.
What is a status page, and what does it show?
A status page pulls a few distinct things onto one screen. Get these right and the page earns its keep during the worst hour of your month.
- Component health. A list of the parts of your service (website, API, dashboard, payments, background jobs) each with a plain status: operational, degraded, or down.
- An incident timeline. When something breaks, you open an incident and post short updates as you investigate, identify, fix, and resolve. The timeline stays public afterward as a record.
- Uptime history. A rolling record, often 90 days, showing how each component has performed. This is the part customers check before they trust you with an SLA.
- Subscribe and notify. Visitors sign up for email, SMS, Slack, or webhook alerts, so they hear about incidents without refreshing the page.
Together these turn a vague sense of "something is wrong" into a clear, timestamped story. The good news is you can also answer those repetitive questions automatically so your team focuses on the fix instead of the inbox.
Public vs internal status pages
Not every status page faces the world. A public status page lives at a URL your customers can reach, usually something like status.yourapp.com. An internal or private status page is locked behind login and used by your own team, or shared only with specific partners under NDA. Both matter, and they serve different readers.
| Aspect | Public status page | Internal / private status page |
|---|---|---|
| Audience | Customers, prospects, the general public | Your team, on-call, sometimes select partners |
| Goal | Cut support load, build trust, prove uptime | Coordinate response, share detail safely |
| Access | Open URL, no login | Password or SSO protected |
| Detail level | Plain language, no internal system names | Full technical detail, component internals |
Many teams run both: a private view with the messy detail, and a public view that says only what a customer needs to know. If you run one page, make it the public one, because that is the page doing the trust work.
Hosted vs self-hosted status page software
There are two ways to get a status page. Hosted status page software is a service that runs the page for you: you configure components, and the provider handles hosting, uptime, and the alert plumbing. Self-hosted means you run open-source status page software on your own servers and maintain it yourself.
The trade is straightforward. A hosted status page is faster to stand up and, importantly, stays online when your own infrastructure does not. That last point matters more than it sounds: a self-hosted page that lives in the same data center as the app it monitors can go dark in the exact outage people came to read about. Self-hosting gives you full control and no per-page fee, at the cost of being one more thing you have to keep running.
For most SaaS teams, a hosted status pages setup wins on reliability alone. The page has to survive your bad day, not share it. If you are weighing specific providers, our rundown of status page software compares the hosted options side by side.
alertping
A hosted status page on every plan
AlertPing includes hosted status pages on every plan, hosted off your own infrastructure so the page stays up when your app does not. One page on Starter, five on Team, twenty on Business.
What makes a good status page
A status page is only worth having if people trust it. Trust comes from a few habits, not from design. A slick page that lies is worth less than a plain one that tells the truth on time.
- It is honest. If a component is degraded, say so. A page that shows all green through a real outage teaches customers to ignore it.
- It is updated during incidents. Post within minutes, then keep posting. Even "still investigating, next update in 30 minutes" is worth sending, because silence reads as chaos.
- It is subscribable. Let people get notified rather than sit refreshing. This is the single feature that pulls them off your support channels.
- It shows real uptime. Publish the actual rolling history from your monitoring, not a hand-edited number. Real data is what a buyer checks before signing.
The failure mode is a page nobody updates. A stale status page is worse than none, because it quietly tells everyone the truth lives somewhere else. If you want to see those habits in the wild, we walk through status page examples from teams that get it right.
Who needs a public status page?
Not every project needs one, but three groups almost always do. SaaS products with an SLA need a page to show they are holding the promise, because the uptime history is the receipt. If you sell a status page for your SaaS as part of an enterprise deal, buyers will ask for the link during procurement. APIs need one because their users are developers who will check a status page before they open a ticket, and often before they even email. Ecommerce stores need one during peak sales, when an hour of confusion about "is checkout broken?" costs real revenue.
If your customers lose money or time when you go down, a public status page pays for itself the first time you have a bad day. It also does quiet work on the good days, because a link to a healthy 90-day history is a sales asset a prospect can verify without asking you a thing.
How a status page relates to uptime monitoring
A status page and an uptime monitor are two halves of one job. The monitor measures: it checks your endpoints on an interval, from multiple regions, and records whether each check passed. The status page publishes: it takes that measurement and shows it to the world. One without the other is incomplete. A monitor with no page keeps the truth private. A page with no monitor is just a box you update by hand, which means it lags reality and eventually drifts into fiction.
With AlertPing, checks run as fast as every 30 seconds on Team and Business plans (60 seconds on Starter), confirmed across three regions so a single flaky network path does not trigger a false alarm. When a real outage is confirmed, the same system that fires your alerts over SMS, email, Slack, or webhook can drive the status page, so the public update and your on-call ping come from one source of truth. Measure once, alert your team, publish to your customers.