Your status page must stay reachable when your product is down, so it should not share hosting, DNS, authentication or email with the product. If an outage takes out both, customers get silence at the exact moment they need information. Separate every dependency you can.
The shared fate problem
Typical failure: the product and the status page sit in the same cloud account and region, on the same domain, behind the same login provider. A region outage or a bad DNS change hides the page too.
What to separate
Hosting. Use a different provider or at least a different account and region from production. Many teams use a dedicated status service for this reason.
DNS. Put the status subdomain with a separate DNS provider or a separate zone, if you can. A mistake in the main zone should not remove it.
Domain. Consider a separate domain as a fallback, listed in your support docs. Customers need a place to look if your primary domain fails.
Login for editors. Do not use the same single sign on that production depends on, or keep a break glass account with its own strong authentication stored offline.
Notifications. Email and chat notifications should come from a path that does not rely on your own mail servers.
Monitoring. External checks must run from outside your network. Internal checks cannot tell you what customers see.
Security of the status page itself
It is a trusted channel, so attackers like it. Protect editor accounts with phishing resistant multi factor authentication, limit who can post, and log every change. A forged "all clear" or a fake link in an update is a real risk.
Also tell customers which address is official, so a lookalike domain cannot fool them in a crisis.
Test it
Once a quarter, during a planned exercise, pretend production is gone. Can the on-call person log in, post an update and send a notification without touching production systems? If not, write down the dependency and fix it.
Quick check
Is a subdomain of our main domain enough?
It is fine for convenience, but treat DNS as a shared dependency and have a plan if the main zone breaks.
Who should be allowed to edit?
A small named group, each with multi factor authentication, and a record of every post.
Last reviewed: 19 October 2026.
