A Datacenter, a Storm, and 24 Million Domains. How Does a Company This Big Go Fully Dark?
On August 13, 2026, a storm knocked out the cooling systems at RadiusDC's Phoenix data center. That facility hosted a large share of Namecheap's core infrastructure. Temperatures inside started climbing toward the point where server hardware risks permanent damage, and Namecheap made the call to power services down rather than let the equipment cook. What followed was roughly 30 hours where hosting, DNS, EasyWP, and private email were unreachable for a huge slice of the company's customer base, along with any third party site that used Namecheap's nameservers, even if that site was actually hosted somewhere else entirely, like AWS or Shopify.
That last part is the detail worth sitting with. Sites that had nothing physically hosted at Namecheap still went dark, because the internet found them through Namecheap's DNS first, and DNS was the thing that broke.
For a company this size, with millions of customers and decades of uptime behind it, the instinct is to assume an outage like this must be rare, exotic, almost a fluke. It isn't. It's the most common shape a big outage takes, and the mechanism is almost always the same one.
Scale Doesn't Remove Single Points of Failure. It Hides Them.
A small company with one server has an obvious single point of failure: the server. Everyone building it knows exactly where the fragility lives, because there's nowhere else for it to hide.
A company the size of Namecheap looks nothing like that from the outside. Multiple hosting tiers, multiple product lines, redundancy language in every piece of marketing copy. But redundancy at the product layer doesn't automatically mean redundancy at the physical layer, and that's where this kind of outage actually lives. A dozen services that all read as independent from a customer's dashboard can still share one physical dependency underneath: one data center, one cooling system, one power feed, one region. The complexity on top is real. It just isn't the thing that failed.
The question worth asking about any large platform isn't "how many services do they run." It's:
If the single physical location housing the most concentrated piece of our infrastructure went dark right now, what fraction of everything else stops with it?
For a huge number of "highly available" systems, the honest answer is a lot more than anyone expected, because the redundancy was built horizontally, across services, and not vertically, across the physical dependencies underneath those services.
Why DNS Specifically Turns a Bad Day Into a Catastrophic One
Most infrastructure failures are contained by design. A hosting outage takes down the sites physically running on that hosting. A billing outage takes down billing. DNS doesn't fail that way, because DNS isn't a service sitting alongside everything else. It's the layer everything else is found through.
When a domain's nameservers stop resolving, it doesn't matter that the actual website is sitting on a completely healthy server somewhere else. Nobody's browser can find it. This is why the Namecheap outage reached far past Namecheap's own hosting customers and into sites that had chosen Namecheap purely as a registrar, years earlier, for a completely unrelated reason, and never thought about it again. DNS concentration risk is invisible until the exact day it isn't, because the dependency doesn't show up in any uptime dashboard you're likely to be watching. It shows up in a decision made once, at setup, and never revisited.
What Actually Explains an Outage This Size
Physical concentration disguised as logical redundancy. Multiple product tiers running through one facility looks diversified from a service map and isn't diversified at all from a power and cooling map.
A single environmental dependency with no fallback fast enough to matter. Cooling failure is a slow-moving crisis until it isn't. Once server hardware is at real risk of permanent damage, the safe move is to power down, and powering down at that scale takes far longer to reverse than it took to trigger.
Dependencies nobody re-evaluates after the decision that created them. A site owner who set their nameservers to a registrar's defaults five years ago almost certainly isn't thinking about that decision today. That's exactly the kind of dependency that turns someone else's data center problem into your outage.
Recovery that has to be sequenced, not flipped back on. Bringing thousands of servers back online safely after a thermal event doesn't happen all at once. Different services return at different times, which means the outage doesn't have one clean end, it has a long tail, and the last customers restored are down far longer than the headline number suggests.
The Decision, Not the Incident
None of this means a company this size is badly run because a data center in Phoenix had a bad day during a storm. It means physical concentration risk is real at every scale, it just gets harder to see as the product surface grows, and the only real defence is treating "what's our actual physical blast radius" as a question worth re-asking on purpose, not something the redundancy language on a pricing page already answered for you.
The same question is worth pointing at your own stack, not just theirs. Which single facility, single provider, or single decision made years ago would take down more than you think if it had a bad afternoon.
Disaster Recovery Steps for This Exact Scenario
If a single facility, provider, or region going dark would take more of your stack down than it should, these are the specific steps that close that gap, roughly in the order they matter most.
Run DNS across two independent providers, not two servers at the same one. Secondary DNS with a different vendor entirely (not just a different nameserver on the same platform) is the single highest leverage fix here. If your primary registrar's nameservers go dark, a properly configured secondary provider keeps resolving without anyone needing to act in the moment.
Audit where your nameservers actually point, today, not at setup. Most domains are still pointed at whatever the registrar set by default years ago. A five minute check per domain now is cheaper than discovering the dependency during someone else's outage.
Lower your DNS TTLs before you need them low, not during the incident. A long TTL means that even after you fix the problem or fail over, caches around the internet keep serving the old, broken answer for hours. Short TTLs on critical records cost almost nothing and buy you a much faster recovery window when it counts.
Separate your registrar, your DNS host, and your compute host on purpose, for anything business critical. Bundling all three with one vendor is convenient and it's also how one physical failure becomes a total outage instead of a partial one. This doesn't mean avoiding bundled convenience for everything, it means being deliberate about which properties are worth the extra operational overhead of separation.
Keep an out-of-band way to reach customers that doesn't depend on your own infrastructure. If your status page, support system, and email all live behind the same DNS that just failed, you have no way to tell anyone what's happening. A status page on a separate domain and DNS provider, plus a social account or SMS channel that doesn't route through your own stack, is what keeps communication alive during the exact moment it matters most.
Write the failover run-book before the incident, and name an owner for triggering it. The Namecheap timeline shows a company making real time, high stakes calls under pressure: power down or risk permanent hardware damage. Decisions like that go faster and cleaner when the criteria and the decision maker were already defined in a document nobody had to write from scratch at 2am.
Test the failover, not just the backup. Having a secondary DNS provider configured and never having switched to it live is not the same as knowing it works. A scheduled, low stakes drill (moving a non critical domain over and back) surfaces the gaps in a config while the stakes are zero, instead of during the thirty hour window when they're not.
None of these steps require predicting the next storm, the next cooling failure, or which specific data center has a bad day. They require assuming, correctly, that something eventually will, and making sure the blast radius when it happens is the one you chose, not the one you inherited by never asking.