Your servers can be switched off by someone you never signed anything with

On 13 August more than 5,000 servers went out of service in a building in Phoenix, and with them the websites, email, control panels and DNS of thousands of companies spread across half the world. No attacker, no CVE. The cooling in the room stopped keeping up and everything had to be powered off before the heat took the hardware with it. The striking part is not the failure itself: the order to shut down did not come from the company those customers pay.

Between a small accountancy firm in Sabadell with its website and its email, and the hand that decided to cut the power, there were several companies — and none of them had signed anything with that firm. That distance is what interests us here, because it can be measured before you sign, and almost nobody measures it.

Thirty and a half hours, with timestamps

The public sequence runs like this. Overnight on 13 August a storm hits RadiusDC's Phoenix data centre. The technical note reported by HostingJournalist is more specific than "a storm": white-space temperatures rise following multiple utility bump events during the overnight storms. At 10:28 UTC the data centre issues its first temperature alert. Equipment is taken out of service in stages over the following hours — more than 5,000 servers in total.

We will not dwell on whether shutting down was right, because we argued that case back in July over the Google Cloud outage caused by power and cooling: a thermal shutdown is the correct decision, not the failure. ASHRAE's thermal guidelines put the recommended inlet temperature range at 18 to 27 °C and the allowable range for class A1 equipment at 15 to 32 °C, and that ceiling describes the condition under which the manufacturer verifies the kit works, with the caveat that running there for long stretches shortens its life. With the room at full load and half the cooling plant stopped, staying powered on meant betting on how long disks and power supplies take to degrade.

The chain the order comes down

Everyone knows the short answer to who can reboot their servers: me, or my provider if I ask. The long list is another matter. In Phoenix, above the end customer sat the agency or partner that built the website, the hosting provider that sold the plan, phoenixNAP — which sold the building business and remains inside as a tenant, and which is the party publishing the technical detail of what happened — and RadiusDC, which runs the room. Four rungs up, none of them holding your phone number.

And the building had changed hands only months earlier. RadiusDC announced on 12 March its agreement to buy phoenixNAP's Phoenix data centre and colocation business, with closing expected in the second quarter. Whoever is in charge today of the room your hardware lives in may not be whoever was in charge when you signed, and that change shows up on no invoice.

The building operator holding that authority is fine: they are the ones watching the thermometers and answerable if the room burns. The problem is that this authority never comes up in the sales conversation, where the talk is of uptime percentages. A percentage is answered with a number from a brochure. The question of who can switch you off is answered with company names, and those names change.

DNS travelled further than the building

When Namecheap DNS stopped answering, sites that were not hosted there broke too. Any website in the world whose nameservers pointed at Namecheap stopped being found, wherever it happened to live. A company that had done its homework — website with one provider, email with another, backups with a third — could still go dark, because all three are located by querying the same zone.

DNS gets concentrated almost always for a reason that is not technical: it comes bundled. You buy the domain, the registrar throws in the zone, and there it stays. Nobody decides to put all their resolution with a single provider; what happens is that nobody decides otherwise — the same drift we wrote about with renewals in the post on expired .es domains. The fix is one of the cheap ones: the protocol has always been ready for secondary nameservers with another operator, and setting it up costs an afternoon. With one caveat worth stating, because it protects less than it appears to: it keeps resolution alive, not the service. If your website is off, secondary DNS will happily answer with the address of a machine that does not reply.

What the numbers say, which is not what you would guess

Here it is worth resisting the easy moral of "go audit your provider's cooling". In the breakdown of causes of IT service outages that Network World draws from the Uptime Institute's 2026 annual analysis, cooling comes last on the list at 8%, behind networking and connectivity (23%), power (21%), system and software (18%) and third-party providers (10%). For data centre outages specifically, power accounts for 45% of those with impact. Phoenix is the rare case, not the typical one.

Which strengthens the argument rather than weakening it. A cause that explains eight outages in a hundred took out 5,000 servers for a day and a half, and reached companies that had nothing in that building at all. Planning by frequency would have helped nobody. Two more figures from the same report are useful for the conversation with management: 57% of respondents say their most recent major outage cost more than $100,000, and for the second year running one in five report costs above a million. Frequency per site, meanwhile, is down for the fifth consecutive year, and only around one in ten say their last outage had serious or severe impact. Those two trends together are how you work out an RTO and RPO with numbers instead of adjectives.

Three questions about the building

We run our own infrastructure across several data centres, so we have both asked these questions and been asked them. They are about the chain of command, which is the part that tends not to be written down anywhere.

When you do not need any of this

We sell colocation and recovery plans, so this paragraph has a vested interest and we say so before writing it. Thirty hours of website downtime does not ruin everybody. If the site is a brochure with a contact form, the email runs on Microsoft 365 and never touches that building, and business happens by phone and over the counter, then secondary DNS with another operator is worth it because it costs little, and duplicating infrastructure in a second data centre is not. Recommending against duplication when the numbers do not add up is part of the job, the same way we have recommended staying on VMware when that made sense.

You cross the line when the business cannot work without it. A warehouse that cannot ship without the ERP, a clinic that cannot run appointments without the records, an accountancy firm at quarter-end. There, a day and a half stopped is measured in revenue, and the price of redundancy stops being compared against zero.

We have spent weeks here writing about versions that expire, advisories with deadlines and bugs with numbers assigned to them. This one has no number, no bulletin to subscribe to, no inventory to cross-check. There was a summer storm over the desert and a building that could not shed its heat. The work that helps here happens beforehand, and it mostly consists of knowing where your things are and who is in charge of the place they are in — even if you never signed anything with them.

Sources (verified on 16 August 2026): incident timeline (first temperature alert at 10:28 UTC on 13 Aug 2026, closed at 17:00 UTC on 14 Aug 2026, 30 h 32 min in total, 11 h 42 min for the main site, more than 5,000 servers, the list of affected services, the effect on third-party sites resolving via Namecheap, the absence of data loss and the announcement of redundancy across its US, European and Asian data centres), from Namecheap's status page and statement as reported by Cyber Kendra; the technical note describing utility bump events during the overnight storms, the simultaneous impact on Hosting.com, and the deal under which RadiusDC takes over phoenixNAP's Phoenix data centre and colocation business (announced 12 March 2026, closing expected in the second quarter; phoenixNAP remains a tenant), per HostingJournalist and the transaction press release; two of four chillers back by midday Eastern Time and the use of temporary chillers, per TechBarrista; recommended (18–27 °C) and class A1 allowable (15–32 °C) thermal ranges from the ASHRAE TC 9.9 thermal guidelines; the breakdown of IT service outage causes (networking 23%, power 21%, system and software 18%, third parties 10%, cooling 8%) and power as the cause of 45% of impactful data centre outages, per Network World's reading of the Uptime Institute's Annual Outage Analysis 2026, which is also the source for 57% above $100,000, 1 in 5 above $1M, the fifth consecutive year of per-site decline and the ~1 in 10 with serious or severe impact. Declared discrepancy: Cyber Kendra and TechBarrista attribute the instruction to take systems out of service to RadiusDC; HostingJournalist presents it as Namecheap's own decision. We were unable to access Namecheap's own statement. Quotations translated from English are our own translations. The reading of the shutdown authority chain, of DNS concentration, and the three questions are ours, not the sources'.