Building a Status Page That Stays Up When You Don't
Here's an uncomfortable thing about status pages: most of them go down with the thing they're supposed to be monitoring.
Your app is on one cloud provider. Your status page is on the same cloud provider. The moment your infrastructure has a bad day, both of them go dark at once — and the page your customers were about to check to find out if you're aware of the problem is the same page that isn't loading.
This is the silent failure nobody talks about until it happens to them. And it happens a lot more than you'd think.
Why it happens
The honest answer is convenience. When you're setting up a status page, the path of least resistance is to host it the same way you host everything else. Same cloud, same build pipeline, same database. It's one less vendor to manage, one less thing to learn, and it works fine every single day — right up until the day it doesn't.
This is exactly the problem a dedicated status page service is supposed to solve. Putting your status page on different infrastructure from your main app is the right call, and it's the reason services like PageCalm exist. You get a page that stays up when your app doesn't, without having to manage a second deploy pipeline, a second monitoring setup, and a second thing to forget about.
But "different infrastructure" can still mean different levels of resilience. A status page that runs on a single cloud provider is vastly better than one that shares fate with your app — and for most teams, that's exactly what they need. The next level up is a status page that keeps serving a useful snapshot even if its own hosting provider has a rough day. That's the bar we set for ourselves, and it's where this story begins.
What customers actually experience
Put yourself on the other side of this for a second.
You're a customer. You just tried to log in to a service and got an error. You pull up their status page to see if they know. The status page doesn't load either. Or it loads but says "All Systems Operational" when you can plainly see things are broken. Or it loads a generic cloud provider error message with no branding, no context, and no next step.
What do you do? You assume the worst. You tweet about it. You email support. You start googling alternatives. You start wondering whether you can trust this vendor with anything important.
A five-minute outage with no status page is a bad experience. A five-minute outage with a clear, working status page that says "we're on it" is completely different. The uptime numbers are identical. The customer experience isn't even close.
The fix isn't "more uptime"
The instinctive response to "my status page goes down with me" is to try harder to stay up. Better monitoring, more redundancy, multi-region deployments. Those are all fine goals, but they cost real money and take real time, and they don't actually address the core problem — which is that the status page and the app share a fate.
The right answer is separation. The status page should live on infrastructure that is as independent as possible from everything else you run. Ideally, it should keep serving useful information even in scenarios where your main app, your database, and your primary cloud provider are all having bad days simultaneously.
That sounds expensive. It doesn't have to be.
What we built for PageCalm itself
We had exactly this problem. PageCalm's own status page — status.pagecalm.com — runs on the same Next.js app that powers the product. When Vercel has an issue, our app goes down and so does our own status page. We were doing the thing we tell customers not to do.
So last week we fixed it. The short version: we put a small piece of code in front of status.pagecalm.com that quietly keeps a fresh copy of the page on completely independent infrastructure. When our main infrastructure is healthy, visitors get the live page, and the copy refreshes in the background. When our main infrastructure has a problem, visitors get the fresh copy served from the independent location instead — with a clear banner at the top letting them know they're looking at a snapshot rather than live data.
The failover is invisible when it isn't needed. The page you see during an outage is the same page you came for, not a cloud provider error screen. It's styled correctly. It reads correctly. The only difference is the banner, and the fact that interactive features — subscribing to updates, filling out forms — are turned off, because during an actual outage those wouldn't work anyway and a disabled input is more honest than a button that silently fails.
status.pagecalm.com is live and running this architecture right now. If you visit it on a normal day, you'll get the live page. If you ever visit it during an outage, you'll see the same content, served from a snapshot, with a degraded-mode notice at the top. You won't get a Vercel error, and you won't get a blank page.
Why this matters for everyone else, not just us
Right now, this protection only covers our own status page. We built it for ourselves first because we wanted to be sure the design actually worked before shipping it to customers. It did — we caught one real bug in testing that only showed up when we loaded the page in an actual browser, fixed it, and re-tested. More on that story another day.
Next, we're extending the same protection to every PageCalm customer's status page automatically. No separate setup. No second domain. No extra infrastructure to manage. You publish a status page on PageCalm, and it quietly gains the ability to survive outages that take down everything else you run.
Status pages exist for the moment when things are broken, and a page that doesn't survive that moment isn't really doing its job. That's the bar we're building toward.
The question worth asking
If you're running a service with a status page right now, there's one question that'll tell you whether you have this problem: if your main infrastructure disappeared this second, would anything still be there for your customers to look at?
For most teams, the honest answer is no. For us, up until last week, the honest answer was also no. Now it's yes — for our own page today, and soon for every customer's page.
Status pages don't need to be complicated. They do need to be there when it counts. If yours isn't, at least now you know what to fix.
PageCalm gives small teams beautiful AI-powered status pages that are simple enough to set up in ten minutes and smart enough to write your customer updates for you. Get started free — no credit card required.