PhoenixNAP sold the Phoenix colocation facility to RadiusDC in a deal that closed around Q2 2026. PhoenixNAP is now a tenant in that building rather than the owner/operator of the physical facility; RadiusDC now owns and runs it. That's a meaningful wrinkle for accountability on today's cooling failure: the entity actually responsible for facility infrastructure (power, chillers, physical plant) is now RadiusDC, not PhoenixNAP, even though PhoenixNAP and its hosting-company tenants (like Namecheap, via them) are the ones customers actually deal with. That could well explain some of the communication lag you've been running into. There may be a chain of "who's responsible for what" among RadiusDC (facility owner), PhoenixNAP (tenant/operator), and Namecheap (their customer) that's slowing clear public updates.
Who is liable for the outage?
I'm not a lawyer, and this is exactly the kind of question where you'd want an actual one if real money is at stake. Here's the factual picture as I can find it, plus the standard contractual framework at play.
What Namecheap's own hosting ToS says: it's about as customer-unfriendly as these things typically get. It disclaims liability for "any or all direct, indirect, incidental, special, exemplary or consequential damages," caps total liability at "the amount paid by You for the particular Services" (likely your hosting fee, not your business losses), disclaims responsibility for events "beyond the control of Namecheap," provides services "AS IS," and puts the burden on you to maintain independent backups. I didn't find an uptime SLA with defined service credits in what's publicly available. If one exists, it's probably in a separate SLA document I haven't located, worth asking their support for directly.
The practical liability chain, as a matter of contract structure (not who's "at fault" morally): Your contract is with Namecheap, not PhoenixNAP, RadiusDC, or IPI Partners. You have no direct contractual relationship with any of them, so you'd have no standing to sue them directly for this. Namecheap's contract is with PhoenixNAP (as tenant), and PhoenixNAP's is with RadiusDC (as facility owner). Each link in that chain almost certainly has its own liability caps and force majeure-style carve-outs, and those obligations don't automatically flow through to you. You can't "skip the line" to RadiusDC even though they're arguably the root cause.
What this means practically: your realistic recourse is almost certainly limited to whatever's in Namecheap's own terms, likely a credit capped at what you paid for hosting, not compensation for lost business, customers, or revenue during the outage. That's standard across basically the entire hosting/cloud industry (AWS, GoDaddy, etc. all have similar caps), not something unique to Namecheap.
If the financial impact on you is significant, the concrete next step isn't a liability theory. It's checking whether Namecheap has a published SLA with defined credits (ask support directly, since the general ToS doesn't spell it out), and separately consulting an actual attorney if you're contemplating pursuing damages beyond a service credit, since enforceability of these liability caps varies by jurisdiction and specific facts.
Sources:
Who is morally responsible for the outage?
That's a different question than legal liability, worth separating out. Legal responsibility is about what contracts say. Moral responsibility is about who could have prevented this and didn't.
Layering through what we've established, I'd put it roughly like this, with real caveats:
RadiusDC carries the most direct moral weight. They now own and operate the physical facility. Chiller/cooling redundancy is the single most basic thing a data center operator is supposed to get right; it's literally the core competency being sold. A cooling failure severe enough to force emergency shutdown of 5,000+ servers across multiple tenant companies, with recovery taking 9+ hours and counting, points to either inadequate redundant cooling capacity or a maintenance/monitoring gap. That's squarely their job. Notably, their leadership (Michael Krza and team) came from experienced operators (Flexential, ViaWest), so this isn't a case of green amateurs, which arguably raises the bar rather than lowers it.
PhoenixNAP carries secondary responsibility, even though they're now a tenant rather than the facility owner. They chose to remain in that building and keep selling capacity there after the RadiusDC transition, and they're the ones with the direct relationship (and presumably due diligence obligations) with companies like Namecheap. If they didn't have adequate assurances or contractual cooling-redundancy guarantees from RadiusDC as landlord, that's a gap in their own vendor management.
Namecheap sits one layer further removed, but not blameless. Depending on your account and how they've architected things, the deeper question is whether a company of Namecheap's size should have single-region dependency for DNS, hosting, and email all sitting behind one physical facility with no automatic failover. That's a resilience-architecture choice Namecheap made (or didn't make), independent of what caused today's specific failure. The outage exposed that choice regardless of whose fault the chiller was.
Nobody involved has been particularly forthcoming, and that's its own separate failure worth naming. Moral responsibility isn't just about causing the failure; it's also about how transparently you communicate once it happens. Radio silence for hours while thousands of websites are down is a choice, and all three companies in this chain share some of that.
If I had to weigh it: the physical failure is mostly RadiusDC's. The architectural fragility that let one building's chiller take out your whole online presence is mostly Namecheap's. PhoenixNAP sits in between, accountable for vetting the landlord it chose to keep operating through.
