To create a status page, pick hosted status page software, list the components you want to show (website, API, dashboard, payments), and connect each one to an uptime monitor so status updates automatically instead of by hand. Then set your subscribe channels (email, SMS, Slack, webhook), publish the page on a status subdomain like status.yourdomain.com, and practice posting incident updates before you actually need to.
That is the whole job in one paragraph. The rest walks each step with the specifics that trip people up. Still deciding whether you need one? Start with what a status page is and come back.
How to create a status page in 6 steps
Here is the full walk-through. None of these steps takes long, and once the page is wired to your monitoring it mostly runs itself.
- Choose hosted status page software. Sign up for a tool that runs the page for you. A hosted page stays up when your own infrastructure is down, which is exactly the moment people come to read it. Skip the ones that host the page next to the app it reports on.
- List your components. Add the parts of your service a customer cares about: website, API, dashboard, payments, and any background jobs that matter. Keep the names plain. "Checkout" beats "payments-worker-v2." Each component gets its own status line so a partial outage reads as partial.
- Connect each component to a monitor. Point every component at an uptime check so the page reflects real data instead of a box you forget to update. When a monitor confirms an outage, the component flips to degraded or down on its own.
- Configure subscribe channels. Turn on the ways people follow the page: email, SMS, Slack, and webhook. This is the single feature that pulls users off your support queue, because they get notified instead of emailing you to ask what is happening.
- Publish it on a status subdomain. Put the page at status.yourdomain.com with a CNAME record pointing at your provider. A subdomain on your own domain looks official and is the URL customers guess first when something feels off.
- Practice incident updates. Open a test incident, post a few updates, and resolve it. Running the flow once when nothing is broken means the real thing later is muscle memory, not a scramble through settings while your phone buzzes.
Step 1: Hosted or self-hosted?
The first real decision is who runs the page. Hosted status page software hosts the page for you, off your own infrastructure. Self-hosted means you run open-source software on your own servers and keep it patched, backed up, and online yourself.
The trade matters more than it looks. A self-hosted page in the same data center as your app can go dark in the exact outage people came to check. A hosted page survives your bad day because it does not share your infrastructure. For most teams building a status page for your SaaS, hosted wins on reliability alone.
| Aspect | Hosted status page | Self-hosted status page |
|---|---|---|
| Stays up in your outage | Yes, runs off your infrastructure | Risky if it shares your servers |
| Time to launch | Under an hour | Hours to days plus setup |
| Maintenance | Provider handles it | You patch, back up, monitor it |
| Cost model | Per-plan fee | No fee, but your time and servers |
Step 2: Define the right components
Components are the rows on your page, and getting them right is mostly about restraint. List the parts a customer would notice: website, API, dashboard, payments. Do not list every internal microservice, because a reader does not care that "queue-consumer-3" is slow, only that checkout works. Group by what breaks for the user, not by how your architecture is drawn.
A good rule: if a component going down would generate support tickets, it belongs on the page. Three to six components covers most SaaS products at launch, and you can add more later.
alertping
Hosted status pages on every plan
AlertPing includes hosted status pages on every plan, run off your own infrastructure so the page stays up when your app does not. Wire each component to a monitor and it updates itself.
Step 3: Connect components to monitors so the page updates itself
This is the step most people skip, and the one that matters most. A hand-edited page lags reality and drifts into fiction, because someone always forgets to flip a switch back. Connect every component to an uptime monitor so the page reads from real checks instead.
| Aspect | Manual updates | Monitor-driven updates |
|---|---|---|
| Speed | As fast as someone notices | Within the check interval |
| Accuracy | Drifts when people forget | Matches real checks |
| Uptime history | Hand-entered, unverifiable | Recorded from actual data |
| 2am response | Someone has to wake up and log in | Page flips on its own |
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 flip your page red by mistake. The same confirmed outage that fires your team's alerts drives the public page, so both come from one source of truth. That verified history is what a buyer checks before signing an SLA.
Step 4: Set your subscribe and notify channels
Turn on subscriptions so people follow the page instead of your inbox. Offer email for the general audience, SMS for customers who need to know the moment something breaks, Slack for teams that live in a channel, and webhooks for piping your status into other tooling. Every subscriber is one fewer "is it down?" ticket during an incident.
You will still get some tickets, and that is fine. During an incident, point the obvious "is it you?" traffic at the status page and route each incoming ticket to the right responder so the ones that need a human do not get lost in the noise.
Step 5: Put it on status.yourdomain.com
Publish the page on your own domain with a status subdomain. Add a CNAME record that points status.yourdomain.com at the host your provider gives you, wait for it to propagate, and the page lives on your brand instead of a generic URL. This is a five-minute DNS change with an outsized payoff: customers guess status.yourdomain.com first, and a page on your own domain reads as official.
Then link that subdomain from your footer, docs, and support autoresponder. The easier the page is to find, the fewer people file a ticket to learn what you already posted.
Step 6: Run incident updates like you mean it
A status page is only worth having if you post to it during incidents. Open an incident within minutes, even if all you can say is "investigating, next update in 30 minutes." Then keep posting through investigating, identified, monitoring, and resolved. Silence reads as chaos; a steady drip of short honest updates reads as a team in control.
Write for the customer, not the engineer. "Checkout is failing for some users, we found the cause and are deploying a fix" tells people what they need without exposing your internals. When it is over, leave the timeline up: that record is what a prospect reads to decide you handle bad days well.
How long does it take to create a status page?
With hosted software, a basic public status page takes under an hour: sign up, add components, connect them to monitors, and point a CNAME at the status subdomain. The DNS record can take a while to propagate, but the setup itself is quick. Self-hosting stretches that to hours or days once you add server setup, patching, and testing.
Common mistakes when creating a status page
The biggest mistake is a page nobody updates. A stale status page is worse than none, because it quietly teaches everyone the real truth lives somewhere else. Close behind is hand-editing status instead of wiring it to monitors, which guarantees the page lags reality. And hosting the page on the same infrastructure as your app means it can go dark in the outage people came to read.
Do you need a monitor to run a status page?
In practice, yes. A status page publishes; an uptime monitor measures. A page with no monitor is a box you update by hand, which drifts out of sync the first busy week. Connecting the two means the page reflects confirmed checks, records real uptime, and flips on its own during an outage, so no one has to log in at 2am.