The Cloud Has a Heat Problem: What a Cluster of Cooling Failures Is Telling Us
Proton, Namecheap, Google Cloud, AWS, and CME Group have all been hit by significant thermal incidents within nine months. That does not prove a trend. It does justify a watchlist.
By OMIKINA Editorial · Published · Updated through
Key points
- Five publicly documented incidents in nine months show that cooling failures can disrupt email, hosting, cloud workloads, and global trading—but they do not yet prove that thermal outages are becoming more frequent. Sources: S1, S2, S4, S5, S6, S7
- Phoenix produced the clearest repeat signal: Namecheap described a cooling failure at RadiusDC on August 13, and phoenixNAP reported another elevated-temperature incident in the same facility on August 20. Sources: S2, S3
- The Google Cloud and AWS reports show why “cooling failure” can be misleading: the visible thermal event may be the final domino in a chain involving utility power, transfer systems, controls, pumps, construction, or shared dependencies. Sources: S4, S5
- AI did not cause the documented Proton or Namecheap incidents, but rising rack densities increase the consequence of any cooling weakness and make thermal resilience a distinct infrastructure risk worth tracking. Sources: S8, S9
One outage became a five-incident watchlist
I went looking for one missing data-center story on August 27 and found a much larger question. Proton had reported a critical cooling failure at its primary Frankfurt facility. The company shifted traffic to backup sites, restored most services within roughly two hours, and said no data was lost. Email and notification delays lingered while the team worked through the queue.
That was not merely another software service interruption. It was a reminder that “the cloud” is a physical machine. Within nine months, thermal incidents also disrupted Namecheap services at RadiusDC in Phoenix, AWS workloads in Northern Virginia, Google Cloud services in the Netherlands, and CME Group markets hosted at CyrusOne near Chicago. Five events do not establish a statistically meaningful trend. They do reveal a category of risk that is easy to hide inside the generic label “service outage.”
Phoenix produced the most important repeat signal
Namecheap’s account of its August 13 outage begins with severe weather and utility disturbances at RadiusDC’s Phoenix facility. Multiple power bumps affected the chillers, white-space temperatures rose, and the operator instructed customers to shut down equipment as a precaution. Temporary chillers were brought in while Namecheap restored services in stages.
A week later, phoenixNAP’s public status page reported elevated temperatures in RadiusDC that again triggered environmental monitoring. The incident was stabilized and resolved, but the repeat matters. One facility had two public temperature events within seven days. That is not proof of a systemic industry pattern. It is exactly the kind of localized recurrence a serious resilience watch should capture.
Cooling failure is often the last domino
Google Cloud’s July incident in europe-west4-a is a useful anatomy lesson. A three-millisecond voltage drop tripped both utility feeds. A diesel rotary uninterruptible power system failed to support one side of the site. A transfer problem, a chiller controller that dropped offline, stopped chilled-water pumps, and a redundant cooling source unavailable during construction combined into a cascade. The affected hall reached 44 degrees Celsius, equipment shut down, and the combined service interruption lasted 14 hours and 55 minutes.
AWS described a different sequence in May: a thermal event caused a loss of power in one facility within the use1-az4 Availability Zone in US-EAST-1, impairing EC2 and EBS resources while teams shifted traffic, deployed additional cooling, and restored service. In both cases, “the cooling failed” is technically true and analytically incomplete. The useful question is which dependency failed first—and which safeguards shared the same weakness.
The trend is not proven
The strongest version of this argument would claim that cooling outages are surging. The public evidence does not support that conclusion. Uptime Institute’s 2026 outage analysis says per-site outage frequency declined for a fifth consecutive year, about one in ten reported outages were serious or severe, and power remained the leading cause. There is no authoritative public series in that report showing cooling incidents rising as their own category.
That is why this article is a watchlist, not a verdict. Public incident reports use inconsistent labels, providers disclose different levels of detail, and thermal failures often disappear beneath power or hardware classifications. The answer is not to force a trend line from five anecdotes. It is to collect the incidents consistently enough that the next analysis can be stronger than the last.
Sources: S7
AI is raising the thermal stakes
There is also a causal boundary worth defending. The records reviewed here do not show that AI caused the Proton or Namecheap failures. A storm, utility disturbances, and facility-level cooling problems are not evidence of an AI workload origin. But AI changes the operating context in which those failures occur.
Uptime Institute reports that more operators are running peak racks at 30 kilowatts or above, while third-party facilities account for a larger share of workload locations. ASHRAE advises operators not to cool racks above 50 kilowatts solely with air and notes that even liquid-cooled systems can leave 10 to 30 percent of heat in components such as power supplies, memory, storage, and networking. Higher density does not automatically create failure. It reduces the room for lazy assumptions about cooling, controls, and residual heat.
Redundancy can share the same weakness
The Google report is especially revealing because the site had layers of redundancy. The failure emerged from the relationship among those layers: power feeds, transfer gear, controls, pumps, an equipment fault, and a cooling source temporarily unavailable during construction. Redundancy on a diagram is not independence in operation.
CME Group’s November 2025 market halt makes the same point from a different direction. In its annual filing, CME said a critical cooling failure caused by human error at its largest data center, operated by CyrusOne, forced it to halt markets and delay reopening until the next day. The lesson is uncomfortable but simple: your application may be distributed while its chillers, controls, procedures, or failure domains are not.
One building can carry an enormous blast radius
Cloud regions, availability zones, and global service brands sound geographically diffuse. The incident reports keep pulling the risk back toward a building, a hall, a cooling loop, or a shared operator. Proton moved traffic between sites. AWS isolated the event to one facility. Google’s detailed account traced a regional service impact to a specific electrical and cooling chain inside one zone.
This is not an argument against cloud architecture or colocation. It is an argument for seeing the physical concentration beneath the logical abstraction. Heat is less impressed by a redundancy claim than a slide deck is. It follows airflow, water, controls, maintenance state, and load.
What OMIKINA should watch next
OMIKINA should build a Thermal Resilience Watch that records the date, facility, operator, affected services, reported temperature, initiating event, cooling topology, backup response, restoration time, recurrence, and evidence quality for every public incident. Each record should separate confirmed facts from operator claims, reporting, and inference.
The watch should also connect thermal events to extreme weather, grid disturbances, construction activity, rack-density disclosures, and third-party facility concentration. The purpose would not be to dramatize every hot aisle. It would be to answer questions that the current record leaves open: Are incidents clustering by climate, facility type, equipment design, operator, or density? How often does cooling fail directly, and how often is it the last visible domino?
The next cloud outage may begin with a pump
The most useful conclusion is also the narrowest one. Cooling deserves its own place in infrastructure analysis. It should not vanish inside a general outage count, and it should not be turned into an AI trend without evidence. The disciplined position is to watch the physical chain, document the recurrence, and keep the causal language honest.
The next major cloud outage may arrive under the name of an email provider, a hosting company, a hyperscaler, or a financial market. The revealing word in the incident report may be much less glamorous: chiller, controller, pump, valve, temperature. Are organizations tracking heat as a distinct infrastructure risk—or letting it disappear inside “service outage”?
Why it matters
AI infrastructure is becoming denser while more workloads depend on third-party facilities and concentrated physical systems. A thermal incident can therefore become an email outage, a cloud disruption, or a market halt. Treating heat as a distinct evidence category will not prove a trend by itself—but it can reveal shared failure modes before the next cascade makes them impossible to ignore.
Sources
- Critical cooling failure at primary Frankfurt data center — Proton Status ·
- Namecheap service outage update — Namecheap ·
- Elevated Temperatures at PHX DC — phoenixNAP Status ·
- Thermal event in a single US-EAST-1 facility — AWS Health Dashboard ·
- Incident report: europe-west4-a power and cooling failure — Google Cloud ·
- CME Group 2025 annual report — U.S. Securities and Exchange Commission ·
- Annual outage analysis 2026 — Uptime Institute ·
- Uptime Institute Global Data Center Survey 2026 — Uptime Institute ·
- Retrofit and modernization strategies for AI data centers — ASHRAE ·
Read OMIKINA's editorial standards · Review corrections · Follow the RSS briefing