Teams love shipping /status inside the main application. It is one deploy, one domain, one cert. It is also a trap: when the app's load balancers melt, the status route melts with them. Customers refresh a 502 and assume the worst — because you gave them nowhere else to look.
Same fate, same outage
Shared failure domain means:
- Same Kubernetes cluster
- Same origin IP space
- Same database the status app needs to render
- Same deploy pipeline that just broke production
Any of those can take the explanation offline with the product.
What "separate" usually means
- A hosted status product on someone else's infrastructure (this is what most small teams should do).
- Or a static page on a different cloud account / Pages / S3+CDN setup you do not touch in the same deploy.
- DNS and TLS that do not depend on your app's runtime.
Custom domains are fine — the hostname can be yours. The servers answering it should not be the ones on fire.
Monitor the messenger
Put an external check on the status URL. If status goes down, that is its own incident — smaller blast radius, but still worth knowing before customers tell you.
The awkward corollary
Your status page will sometimes be up while the app is down. That is success. It feels weird the first time. It is the point.
For whether you need a page at all, see do you need a status page for a small SaaS. For honesty once it exists, keep the data tied to real monitors — not a manual green switch on the same box that just died.
