Hosted Status Page: The Shared-Fate Test That Decides It
A hosted status page is worth it for one reason: it does not share your network, certificate, DNS zone or login. Here is how to check that it really doesn't.
A hosted status page runs on infrastructure that is not yours, which is the whole point of it. When your platform is unreachable, the page reporting that fact has to be reachable. Every other consideration, from branding to component naming, is downstream of one question: does this page share any failure domain with the product it describes?
What a hosted status page actually buys you
A public page, run as a service, showing the current state of your components and the history of your incidents. The provider owns the servers, the certificate renewal and the subscriber list. You own the component names, the incident text and whichever domain you point at it.
What it replaces is worse than nothing: a tweet nobody sees, a banner inside the application that is down, and a support inbox filling with the same question. Uptime Room serves pages at /status/<slug> with components, incidents, maintenance windows, subscriber emails and an RSS feed. The free tier gets a page on a subdomain and paid plans add a custom domain, as of September 2026.
Why does running your own status page usually fail?
Because it goes down with you. A page living in the same cloud account, the same region, the same cluster or the same DNS zone as the product is not a status page. It is a second symptom, and it is silent at exactly the moment it was bought to speak.
Work through every place a self-managed page can share fate with the product.
- Same VPC or same Kubernetes cluster as the application.
- Same CDN or same edge provider account.
- Same DNS zone, so a bad zone change takes both out.
- Same database cluster, because someone reused the connection string.
- Same identity provider for the admin login.
In our testing the one that catches people is the last. Compute gets separated early, because that part is obvious. The login does not. If your identity provider is the outage, you cannot sign in to announce that your identity provider is the outage.
Hosted or self-managed, honestly
Both work. They fail differently, and the table below is the trade rather than a scoreboard.
| Question | Hosted service | Run it yourself |
|---|---|---|
| Up when your platform is down | yes, different provider entirely | only if you deliberately separate it |
| Certificate renewal | the provider's problem | yours, and it expires on a Sunday |
| Subscriber email during an outage | the provider's sending reputation | your domain, possibly your broken mail path |
| Where incident data lives | the provider's database | your database |
| Cost at ten thousand subscribers | usually priced per subscriber | hosting and your time |
| Time to a working page | minutes | an afternoon, then patching forever |
Cachet is the long-standing self-managed option and it runs wherever you put it, which means the separation is entirely your discipline. Upptime is the interesting exception: it builds a static page from a GitHub Actions workflow and serves it from GitHub Pages, so it lands on somebody else's infrastructure by design.
We prefer a hosted status page for anything with paying customers and Upptime for a side project. The reason is not features. A static page on a third party's network gets the shared-fate question right without anyone having to remember it.
The row people argue about is data control, and it is usually the weakest one. Incident text is written to be public. Component names are already on your marketing site. The genuinely sensitive part is the subscriber list, so ask a provider how you export it before you need to.
Where the page lives, and the DNS trap
Three addressing options, in ascending order of how much they can hurt you. The provider's own subdomain. A status. subdomain of your domain, pointed at the provider with a CNAME. A separate domain you own.
The middle option is the popular one and it carries a quiet dependency. A CNAME at status.example.com still resolves through your zone. A nameserver change, a registrar lock, an expired domain or a bad infrastructure apply takes the status page down alongside everything else, and the provider never even sees the request.
dig +short NS example.com
dig +short NS status.example.com
Matching nameservers on both lines means one zone is a single point of failure for the product and for the page that reports on the product. GitHub's answer is worth copying: their page lives at githubstatus.com, a separate registrable domain, not a subdomain of the site it reports on.
If a second domain is too much, keep the provider's subdomain alive as a documented fallback. Put that URL in your runbook, your support macros and your incident templates, so nobody has to invent it while the zone is broken.
What has to be true before the outage
A hosted status page is only useful if it works under conditions you have not rehearsed. Five things to settle while nothing is on fire.
- The page exists and is public already. Creating one mid-incident costs the twenty minutes you needed for the first update.
- Somebody other than the on-call engineer can post. One person with the password is one person asleep.
- The admin login does not route through your own single sign-on. Keep a break-glass credential that the outage cannot touch.
- Update templates are written. Our guide to incident communication has a set organised by phase and severity.
- The URL is already in your footer, docs and support auto-replies, so customers find it without asking anyone.
Rehearse item three specifically. It is the one nobody tests, and it turns a five-minute update into an hour of hunting for whoever holds the recovery codes.
Item one deserves a word too. An empty page with one component and no incident history is still worth publishing, because the first time a customer visits should not be the first time it exists. Add components as you add checks, and let the history build itself.
Letting confirmed checks drive the components
Components can be wired to monitors so a failure flips the component without anyone touching the page. This is the difference between a page that is accurate and a page that is accurate whenever somebody remembers.
The REST API covers the monitors behind the components, while the page itself is assembled in the dashboard. A check that drives a public component should be conservative about what counts as down.
curl -X POST https://uptimeroom.com/api/v1/monitors \
-H "Authorization: Bearer urm_live_..." \
-H "Content-Type: application/json" \
-d '{"name":"checkout","type":"http","target":"https://example.com/api/checkout/health","intervalSec":60,"regions":["london","sao-paulo"],"alertAfterCycles":2}'
Two regions and two failed cycles before it counts, because a public page that flickers red on one bad network hop trains customers to ignore it. The reasoning behind requiring agreement between regions is set out in cross-region quorum confirmation, and the six probe regions available as of September 2026 make that cheap to arrange. Teams that filter inbound traffic at the edge will want the addresses on the probe IPs reference first.
Automation has a limit, and it is honesty. A machine can flip a component to degraded. Only a person can write the sentence explaining what customers should do about it, and pages that never carry that sentence are the ones people stop opening. Six real pages are graded on exactly this in our status page examples roundup.
Common mistakes
Putting the page in the same DNS zone as the product. The CNAME looks independent and is not. Check the nameservers, not the hostname.
Letting the page stay green through a known incident. Usually a login problem rather than a policy problem, and it is fixable in advance with a second admin and a break-glass credential.
Publishing every blip. One failed check from one region is not an outage. Confirm before the component turns red, or the page becomes background noise.
Choosing a hosted status page is really choosing what it does not share with you: not your network, not your certificate, not your zone, and not your login. Get those four right and the rest is naming components in words customers recognise. A page on a subdomain is included from the free tier upward as of September 2026, so the separation costs nothing to start.
FAQ
A hosted page runs on the provider's infrastructure, so it stays reachable when yours is not. A self-managed page runs wherever you put it, which means the separation is your responsibility. Upptime is the exception worth knowing: it builds a static page and serves it from GitHub Pages, landing on third-party infrastructure by design.
Cachet is the long-standing choice and runs anywhere you can run PHP, which puts the separation entirely on your discipline. Upptime is better for small projects because it generates a static page from a GitHub Actions workflow and serves it from GitHub Pages, so it is not sitting in the account that just went down.
Only if you accept the dependency. A CNAME at status.example.com still resolves through your DNS zone, so a nameserver change or an expired domain takes the page down with the product. GitHub publishes at githubstatus.com, a separate registrable domain. If a second domain is too much, keep the provider's own subdomain as a documented fallback.
Yes, by wiring components to monitors so a confirmed failure flips the component state. Keep the checks conservative, requiring agreement from two regions and two failed cycles, or the page flickers on ordinary network noise. Automation handles the state; a person still has to write what customers should do about it.
Create the page before you need it, give at least two people posting access, and keep the admin login off your own single sign-on. If your identity provider is the incident, single sign-on means you cannot log in to report it. A break-glass credential stored outside your stack solves it.
Related reading
- Status Page Examples: Six Public Pages, Graded - Six real status page examples judged on their component lists and machine-readable endpoints rather than their design, with what each one is worth copying.
- Incident Communication: Templates and a Cadence - Incident communication works when the first update ships in minutes. Here are the templates, the cadence by severity, and who posts each one.
- Cross-Region Quorum: How Confirmation Stops False Alerts - Cross-region quorum means a target is only called down once probes in more than one region agree. Here is the voting rule, its cost and its limits.