Update: I ended up self-hosting all assets. Nothing broke. Performance improved. Follow-up coming. Follow-up:
A status page exists for exactly one reason:
to be reachable when everything else is broken.
And yet, a surprising number of status pages depend on the same third-party infrastructure that often causes the outage in the first place.
This isn’t a theoretical problem. It’s an architectural contradiction.
TL;DR (for busy engineers and founders)
- Status pages are critical infrastructure, not marketing assets
- Third-party CDNs (including major ones) do have global outages
- When a CDN fails, status pages that depend on it often fail silently
- A
200 OKpage that doesn’t render correctly destroys trust - Fewer dependencies > better incident communication
- Boring, self-hosted, dependency-light status pages outperform pretty ones during real outages
If your status page can go down during an incident, it’s not doing its job.
Let’s talk about why relying on third-party CDNs for status pages is a bad idea, what breaks in practice, and which tradeoffs are usually swept under the rug.
Real Recent Outages (2025–2026)
CDNs and edge providers occasionally fail, often in dramatic fashion:
Cloudflare global outage - November 18, 2025
A faulty configuration change caused widespread HTTP 5xx errors across Cloudflare’s network, impacting services such as ChatGPT, X (Twitter), Spotify, and others.
https://www.forbes.com/sites/kateoflahertyuk/2025/12/05/cloudflare-down-new-outage-takes-internet-down-again/Cloudflare outage - December 5, 2025
Less than three weeks later, another Cloudflare incident affected roughly 28% of all HTTP traffic served by its network due to internal system failures.
https://blog.cloudflare.com/5-december-2025-outage/Secondary impact on monitoring and reporting tools
During these outages, even third-party outage trackers struggled because they relied on the same CDN infrastructure.
https://deployflow.co/blog/cloudflare-outage-explained/
These weren’t cyberattacks. They were internal misconfigurations and cascading failures that propagated globally because of shared infrastructure.
- AWS CloudFront outage - February 10, 2026 Amazon CloudFront suffered a global incident affecting DNS resolution and propagation of configuration changes. Some distributions returned NXDOMAIN, and any changes to CloudFront configs or even creation of new distributions were delayed for hours. Cache invalidations still worked, but that didn’t help teams trying to ship fixes during the outage.
In short: if your app or status page depended on CloudFront, you might have been up, but unable to change or recover anything when it mattered most.
The Core Paradox
When users visit your status page, something has already gone wrong.
Their app doesn’t load.
Their API calls fail.
Their team chat is on fire.
Now add this to the mix:
- Your main app is down
- Your CDN is degraded or unreachable
- Your status page is… also unreachable
You’ve created a single point of communication failure.
At that moment, the status page isn’t merely useless.
It actively increases frustration, support tickets, and distrust.
“But CDNs Are Highly Available”
Usually.
Until they aren’t.
CDNs can fail in inconvenient ways:
- DNS resolution issues
- Regional routing failures
- TLS or certificate problems
- Cached error pages that refuse to expire
- Partial outages that affect “only some users”
And when CDNs fail, they often fail globally, loudly, and at exactly the wrong time.
A status page should not share blast radius with:
- Your main application
- Your analytics stack
- Your marketing site
- Someone else’s JavaScript experiment
The Silent Failure Mode Nobody Talks About
Here’s the one that causes the most damage.
Your status page responds with 200 OK, but:
- External CSS doesn’t load
- Fonts time out
- JavaScript never arrives
What users see:
- Unstyled text
- Blank screens
- Infinite loading indicators
What support teams hear:
- “It works for me.”
What users think:
- “They’re hiding something.”
Trust dies quietly here.
Incident Communication Is a Critical Path
During an incident, your status page becomes critical infrastructure.
It is not:
- A marketing surface
- A design showcase
- A frontend playground
Its job is brutally simple:
- Load fast
- Load reliably
- Say something truthful
Every external dependency increases the chance that it fails at the exact moment you need it most.
“Self-Hosting Everything Is Overkill”
It isn’t. It’s an intentional constraint.
Self-hosting forces discipline:
- Smaller payloads
- Fewer scripts
- Fewer fonts
- Fewer clever ideas
A status page does not need:
- Five font weights
- Client-side hydration
- A/B testing
- Analytics beacons firing during outages
It needs to render. Period.
The Tradeoffs (Because Yes, They Exist)
Avoiding third-party CDNs means:
- You handle asset delivery yourself
- You lose some edge caching convenience
- You think about cache headers and invalidation
- You accept “good enough” over perfect Lighthouse scores
Ask the real question:
Do you want your status page optimized for benchmarks, or for reality?
A Simple Rule of Thumb
If a dependency can fail as part of the same incident you’re communicating about, it should not be required for your status page to load.
That includes:
- CDNs serving your status page assets
- External analytics
- Third-party fonts
- Tag managers
- Anything that blocks rendering while phoning home
Your product may depend on shared infrastructure.
Your status page should not.
Assume the outage affects more than just your app. Design accordingly.
The Uncomfortable Truth
Most status pages are designed for calm days, not bad days.
They look great in screenshots.
They demo well.
They fail quietly when they matter most.
A status page should be boring, resilient, and slightly paranoid.
That’s not a flaw.
That’s the point.
I’m building StatusPage.me around this exact constraint: incident comms that don’t collapse when edge networks do.
Top comments (2)
This post came out of a few real incidents where a "working" status page wasn’t actually usable because external assets or CDNs were degraded.
I’m not arguing that CDNs are bad. They’re fantastic for most things.
But incident communication is a different problem space, with different failure modes and incentives.
Curious how others approach this:
Genuinely interested in real-world setups and tradeoffs, not absolutes.
Updated the post to include the February 10, 2026, CloudFront outage.