RadiusDC Phoenix Outage Caused by Major Cooling Failure

RadiusDC Phoenix Outage Caused by Major Cooling Failure

A major cooling failure at RadiusDC Phoenix I DC1 in Phoenix, Arizona forced infrastructure offline on August 13 after storm-related utility disturbances affected multiple chillers and temperatures inside the data center climbed to unsafe levels.

The RadiusDC Phoenix outage lasted for much of the day as technicians worked to restore cooling, bring temperatures back under control, and eventually begin powering equipment back online. The failure affected infrastructure belonging to multiple companies operating from the facility, with public incident reports confirming disruptions to hosting, cloud infrastructure, email, network equipment, customer websites, and other services.

RadiusDC described the initial problem as elevated white space temperatures caused by multiple utility “bump” events during overnight storms in the Phoenix area. Vendors were brought on site to work on the cooling system while RadiusDC deployed temporary cooling equipment and worked to restore individual chillers.

The outage eventually became much more serious than elevated temperatures or intermittent equipment reboots. Hosting.com, which operates infrastructure at the facility, reported that the cooling failures ultimately caused a shutdown of all equipment in the building, including network provider equipment and power to its servers.

Multiple Chillers Were Affected at RadiusDC Phoenix

RadiusDC Phoenix I DC1 is located at 3402 E University Drive in Phoenix. The 151,000-square-foot facility has 10.5 MW of utility capacity and two operating data halls with up to 3 MW of critical load. RadiusDC lists the critical load design and dedicated generator capacity as N+1, and the facility connects to more than 40 carriers and multiple network on-ramps.

The first public warnings appeared early on August 13 when phoenixNAP, a tenant at the facility, reported higher ambient temperatures in its Phoenix environment. The situation continued to deteriorate through the morning as RadiusDC and on-site vendors worked on the affected cooling systems.

RadiusDC later told customers that multiple utility bump events associated with overnight storms had affected the facility’s chillers. By 7:45 a.m. local time, Chiller D had been restored. Temporary floor cooling and heat-removal equipment was added around 10 a.m., while technicians continued working to restore another chiller. RadiusDC also planned to bring in an additional temporary chiller and temporary backup generator as part of the response.

Those efforts continued for hours. By mid-afternoon, RadiusDC had restored a third chiller and temperatures were beginning to stabilize. Only then could teams inside the facility begin working through offline equipment, physically checking devices and bringing systems back online.

The public updates do not yet explain exactly why the storm-related utility disturbances affected enough of the cooling system for temperatures to rise this far. They do show that the incident involved multiple chillers, temporary cooling equipment, outside vendors, and a prolonged recovery before the environment was considered safe enough to begin restoring equipment.

Infrastructure Across the Data Center Was Taken Offline

The impact extended well beyond a single company or server cluster because the failure occurred at the physical data center itself. RadiusDC Phoenix is a colocation and interconnection facility used by multiple infrastructure providers, networks, and customers.

Hosting.com reported that multiple cooling units failed after the overnight storms and said the situation eventually caused all equipment in the building to be shut down. At the time of that update, roughly half of the building’s cooling capacity had been restored, but technicians were still waiting for conditions to become safe enough to access equipment and restart systems.

phoenixNAP also lost services running from RadiusDC PHX-01, including Bare Metal Cloud, Bare Metal Servers, Data Security Cloud, and other infrastructure. Its support portal and email ticket system were also unavailable during parts of the incident. phoenixNAP remained a tenant at the Phoenix facility after RadiusDC acquired the data center and colocation business earlier this year.

Namecheap confirmed that some of its essential infrastructure is also located inside RadiusDC Phoenix. The company said RadiusDC instructed it to take systems offline after temperatures around its equipment reached critical levels. Namecheap’s hosting platforms, EasyWP, Private Email, DNS management, support systems, and other services were disrupted before gradually returning as the facility recovered.

These companies provide some of the clearest public accounts of the outage, but they do not represent the full scope of infrastructure inside RadiusDC Phoenix. The facility supports more than 40 carriers in addition to its colocation customers, and RadiusDC has not publicly identified every tenant or network affected by the shutdown.

Recovery happened gradually as cooling returned and equipment could be safely inspected. phoenixNAP reported that the third chiller had been restored shortly after 3 p.m. local time and that temperatures were stabilizing. Teams then began physically checking devices and powering equipment back on throughout the environment.

By the evening, services were returning across the facility. phoenixNAP reported its RadiusDC PHX-01 infrastructure back online later that day, although its support systems took longer to recover. Hosting.com also reported services returning as facility temperatures stabilized before marking its Phoenix incident resolved later that night.

The Full Cause of the RadiusDC Phoenix Outage Is Still Being Investigated

The immediate sequence is now fairly clear. Storm-related utility disturbances affected multiple chillers, cooling capacity dropped, temperatures inside the facility rose, equipment was taken offline, temporary cooling measures were deployed, and services were gradually restored as chillers returned to operation and temperatures stabilized.

What is not yet public is the complete technical explanation for why the cooling system reached that point.

RadiusDC lists N+1 critical load and dedicated generator capacity for the facility, but those specifications do not describe the complete cooling architecture or establish what cooling redundancy was available at the time of the incident. It would therefore be premature to assume which specific component or redundancy layer failed beyond the chiller problems RadiusDC has already acknowledged.

phoenixNAP says it is waiting for a formal Reason for Outage report from RadiusDC and plans to provide its own RFO after receiving it. That report should provide a clearer explanation of the utility events, the chiller failures, how the facility responded, and what changes RadiusDC plans to make following the outage.

The incident also comes only months after RadiusDC announced its acquisition of phoenixNAP’s Phoenix data center and colocation business. The transaction included the existing facility, its interconnection infrastructure, and development rights for the surrounding Phoenix I campus. phoenixNAP remained a tenant after the transaction.

RadiusDC has much larger plans for the property. The existing DC1 building is planned to expand to 8 MW of IT capacity, while RadiusDC Phoenix I DC2 is planned to add as much as 18 MW of additional critical capacity. RadiusDC expects the Phoenix I campus to eventually reach approximately 26 MW of total critical IT capacity.

That makes the August 13 outage an important incident for the existing facility. A series of storm-related utility disturbances affected multiple chillers, temperatures rose high enough that infrastructure had to be shut down, and technicians spent much of the day restoring cooling before equipment across the data center could safely return to service.

RadiusDC Phoenix I DC1 is back online, but the final technical explanation for the outage has not yet been released. Botcrawl will continue tracking the incident and update the RadiusDC Phoenix I DC1 record when RadiusDC releases additional verified information about the failure and recovery.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.