What Happens to Your Status Page When Your Product Goes Down?

The worst status page failure is not an awkward update. It is a browser error on the status URL while your product is down. Customers already suspect you are having an outage. They open the page that exists to confirm you know, and the page shares fate with the thing that just broke. That is worse than having no status page. Silence can be incompetence. A dead status page looks like you are down and unaware.

I have watched this happen on a shared cluster where the API, the admin UI, and the status route all talked to the same database. The database locked up. So did the status page. Support started pasting screenshots of the error into the incident channel. Nobody needed more irony that day.

Why this failure mode is so common

The path of least resistance is to ship status inside the main application. Same repo, same deploy, same region, same database row for component state. It is fast to build and easy to keep looking consistent on good days.

On bad days, fate sharing becomes the design. A region outage, a database failure, a deploy that takes down the web tier, or a DDoS aimed at your primary domain can remove the status page along with the product. The more tightly you coupled them for convenience, the more reliably they fail together.

What independent hosting means

Independent hosting means the status page does not need your primary application to be healthy in order to answer HTTP requests with the current status.

In practice that usually means several of these at once.

• Hosted in a different cloud provider or at least a different region from the primary app.
• Served through a CDN with cacheable responses so the edge can keep serving if the origin is sick.
• Implemented as static HTML, a small decoupled app, or a SaaS status product with its own infrastructure.
• Able to render current status without querying the primary product database.

Independence is about failure domains, not about branding. Your status page can still look like your company. It should not die like your API.

For the communication job the page exists to do, see what status pages are for. This post is about keeping that job reachable.

The subscriber notification dependency

Hosting the HTML independently is only half the problem. Many teams also send email or SMS from the same application workers, the same mail provider config stored in the same database, or the same VPC that just went dark.

If subscribers opted in to outage notifications and those messages cannot send without the primary app, you have a second silent failure. The page might be up on a CDN while the notify path is dead. Test both.

A clean pattern is to drive notifications from the status system itself, or from a queue and mail path that do not require the production API to be serving traffic.

Three architecture options

1. Hosted SaaS status page

Use a status product that runs on its own infrastructure. Atlassian Statuspage, Better Stack, and Vigiles status pages all sit in this category. You update components through their UI or API. Customers hit their hosting and CDN story, not your API cluster.

This is the simplest option for most teams. You give up some DIY control and remove a failure domain you did not want to own during an incident.

2. Static site on a separate host

Publish a static status site to Cloudflare Pages, Netlify, or object storage plus CDN. Updates are manual edits, CI jobs, or small API-driven rebuilds from a system outside the primary app. Keep the source of truth in a file or datastore that is not your production OLTP database.

This works well if you want full control of the front end and already live in a static-hosting workflow. The discipline required is updating the static truth quickly during an incident.

3. Separate cloud account and region

Run a tiny status app in another account and region, with its own datastore or file-based state. Replicate status events into it from monitoring, not from the primary app's request path. This is more engineering work. It makes sense when compliance or customization rules out SaaS and static publishing.

Whatever you pick, draw the dependency arrows. If an arrow points from status rendering back into the primary database, you have not finished.

How to test before a real outage

Do not wait for the shared-fate outage to learn the answer.

Primary infrastructure drill. Block or stop the primary app origin in a staging environment that mirrors prod topology, or run a game-day where the production status URL is checked while the primary app is intentionally unreachable from the public internet. The status URL should still load.

DNS and domain check. If status lives on status.example.com, confirm it does not require the same load balancer or WAF rule set that you are about to lose in the failure you care about. Separate hostname helps only when the hosting behind it is separate too.

Subscriber notification test. Trigger a test incident update and confirm email or SMS delivery without the primary app running. If delivery requires a worker that only runs in the primary cluster, fix that before the next real SEV.

Cache behavior. If you rely on CDN caching, verify what visitors see when origin updates are blocked. A cached "all good" page during a two-hour outage is its own credibility problem. Independence includes being able to publish a degraded state while the product is down.

Write the drill results in the runbook next to the status page login. The night you need it, nobody should be asking whether the page shares a database with checkout.

Keep the messenger alive

A status page is a trust tool for bad days. If it shares fate with the product, it fails at the only moment it matters. Put it in a different failure domain, make sure subscriber notifications do not need the primary app, and rehearse the path.

Vigiles hosts public status pages on infrastructure separate from your primary application so the page can stay reachable when your product does not. Pair that with honest updates and you have a status practice customers can actually use during an outage, not only after restore.