Why Your Status Page Should Run on Separate Infrastructure: The Shared-Fate Test

A status page hosted on the same infrastructure as the service it reports on will be unreachable during the outages it exists to explain. That is the whole argument, and it is not hypothetical: the failures large enough to warrant a status update are frequently the same failures that take down everything in the same account, region, or network.

This article covers the five dependencies that have to be independent rather than just the obvious one, why DNS is the most commonly missed, what genuinely acceptable shortcuts look like, and how to verify the independence you think you have. Hosting is the dependency everyone thinks of and it is only one of five.

The five shared-fate dependencies

Call this the shared-fate test: for each of these five, ask whether a failure could take out both your service and your status page. If the answer is yes for any of them, that dependency is not independent, whatever the hosting arrangement.

Hosting. The obvious one. Same server, same cluster, same cloud account, or same region all count as shared. A cloud region failure is one of the most common causes of a large outage and it takes everything in the region with it.

DNS. The most commonly missed. If status.example.com is served by the same DNS zone and the same nameservers as example.com, then a DNS misconfiguration, a zone deletion, an expired domain, or a nameserver outage takes both down simultaneously. This one hurts because DNS problems are common and the failure is total.

CDN and edge.** If both sit behind the same **CDN** account or the same edge configuration, a bad rule deployment or a provider incident affects both. Sharing a provider is survivable; sharing the configuration is not.

Authentication. If updating the status page requires logging into a system that depends on your production identity provider, you cannot post an update during an authentication outage. This is a real and often-discovered-late problem.

The alerting path. If the mechanism that tells you to update the page runs on the same infrastructure, you may not learn about the outage in the first place.

Our guide to setting up a status page covers the configuration side; this is the architectural decision that sits underneath it.

Why DNS is the one that catches people

Teams generally get hosting right and get DNS wrong, because DNS independence is less visible and the shortcut is convenient.

The typical arrangement is a status page hosted by a third party, which is correct, addressed by a CNAME at status.example.com pointing to the provider. That CNAME lives in your zone. Your zone is served by your nameservers. If anything happens to that zone or those nameservers, the status page becomes unreachable even though it is running perfectly on infrastructure that is entirely unaffected.

The failure modes are unglamorous and frequent: an expired domain registration, a zone accidentally deleted during a migration, a DNS provider outage, a botched nameserver change, a DNSSEC misconfiguration. All of them take down the status page along with the service, and all of them are exactly the kind of incident that generates a lot of confused customers.

There are two honest answers. Use a separate domain entirely for status, which is maximally independent and slightly awkward because customers do not know to look for it. Or accept the shared zone and make sure the status page provider's own address is documented somewhere customers can find it, so there is a fallback that does not depend on your DNS at all. The second is what most teams should do, and the important part is deciding it deliberately rather than discovering it during an incident.

What counts as acceptable independence

Full independence is expensive and unnecessary. The practical target is that no single failure takes out both, and that admits several reasonable arrangements.

Using a third-party status page provider is the normal answer and it is a good one. Their infrastructure is entirely separate from yours, they have their own redundancy, and the operational burden is theirs. The residual dependency is your DNS, discussed above, and your ability to log in and post.

Self-hosting in a different cloud provider is defensible if you have a reason to. Self-hosting in a different region of the same provider is weaker, because account-level problems including billing failures, credential compromise, and provider-wide control plane incidents still hit both.

Hosting the status page in the same account as production is not independence in any meaningful sense, regardless of which region or which cluster. The account is a shared dependency and account-level failures are not rare.

One useful test that costs nothing: work out whether you could publish an update from a phone, on mobile data, without access to any production system. If the answer is no, the independence is theoretical.

How to verify what you actually have

Trace each of the five dependencies rather than assuming, because arrangements drift as infrastructure changes.

Resolve your status hostname and see where it points, then check which nameservers serve that zone and compare them to your main domain. If they match, DNS is shared. Check whether the status page sits behind the same CDN or edge configuration. Check what identity system the status page admin login uses, and specifically whether single sign-on routes through anything you run.

Then do the drill, because reasoning is not the same as testing. Pick a quiet afternoon, and have someone attempt to post a status update with no access to production systems and no corporate network. What breaks in that exercise is what will break during an incident, and it is usually cheaper to find out on a Tuesday.

Finally, monitor the status page itself, from outside, as a distinct check. A status page nobody has verified in six months is a plausible candidate for having quietly broken, which is one of the reasons status pages report operational during outages, and the day you discover it is by definition a bad day.

Common mistakes in hosting a status page

Hosting it in the same cloud account as production. A different region is not independence. Account-level failures including billing, credentials, and control-plane incidents take out everything in the account.

Serving the status hostname from the production DNS zone. The most common gap. A DNS failure, expired domain, or bad nameserver change removes the status page and the service together.

Requiring production single sign-on to post an update. If your identity provider is part of the outage, you cannot publish. Keep a login path that does not depend on anything you run.

Never monitoring the status page. It is a production system for your customers. Check it from outside on a schedule, or you will find out it has been broken when you need it.

Assuming a third-party provider makes you fully independent. It removes the hosting dependency and leaves DNS and login. Those two need their own answers.

FAQ

Why should a status page run on separate infrastructure?

Because the outages large enough to need a status update frequently take down everything sharing that infrastructure. A page hosted alongside the service becomes unreachable at precisely the moment its entire purpose applies.

Is a third-party status page provider enough?

It handles the largest dependency, which is hosting, and it is the right default. Two dependencies usually remain: the DNS zone serving your status hostname, and whether posting an update requires an identity system that could be part of the outage.

Should the status page use a different domain?

It is the most independent option, and the trade-off is that customers do not intuitively know to look for it. Many teams keep a subdomain and accept the shared DNS risk, which is fine as long as it is a decision rather than an oversight.

How do I know if my status page is genuinely independent?

Try to publish an update from a phone on mobile data with no access to any production system. Whatever blocks you in that exercise is a shared dependency, and it will block you the same way during a real incident.

Closing thought

The reason this keeps happening is that a status page does not feel like production infrastructure. It is a small static site that nobody looks at most of the time, so it inherits whatever hosting was convenient and whatever DNS zone was already there. Then it spends its entire useful life in exactly the conditions that convenient hosting and shared DNS do not survive. It is the one system in your estate whose availability requirements are the inverse of everything else's.

The same logic applies to the checks behind it. Odown runs status pages on your own domain over HTTPS on every plan, driven by checks from seventeen global locations that sit entirely outside your infrastructure. A status page fed by measurements from within the thing that broke has a shared-fate problem of its own, even when the hosting is separate.