The August 13, 2026 Namecheap Outage
Introduction
Namecheap took more than 5,000 servers offline on August 13, 2026 after cooling systems failed at RadiusDC's Phoenix datacenter, and brought services back in stages over roughly 28 and a half hours. The shutdown was deliberate, intended to protect hardware from overheating. It reached most of the product line - hosting, EasyWP, Private Email, DNS management, URL redirect management and the support helpdesk - while DNS zone resolution was unaffected. The emergency maintenance post opened at 12:35 UTC on August 13 and was marked resolved at 17:00 UTC on August 14.
- Introduction
- Methodology and Coverage
- Timeline of the Outage
- Impact and Root Cause
- The Recovery
- What Namecheap Says Comes Next
- Conclusion
- FAQ
Methodology and Coverage
This write-up is based on Namecheap's own emergency maintenance post, its retrospective blog post of August 14, and the public statement posted by Hillan Klein, CEO of Namecheap, on August 13. Facility-level detail comes from the phoenixNAP outage report, which republished the datacenter operator's (RadiusDC) customer bulletins verbatim, with timestamps, throughout the day.
Important Note: phoenixNAP is a separate company that publishes its own status page, and on the same day it published an outage report for higher ambient temperature in the Phoenix DC naming RadiusDC as its datacenter provider. Namecheap has never linked to that incident, referenced phoenixNAP’s outage, or named PHX-01. The two are connected here by common data points - same day, same city, same operator named, same chiller failure attributed to the same storms. This is not a documented fact but an inference, and it is treated as one throughout this article. phoenixNAP’s incident is used as a separate data point that happens to carry RadiusDC’s customer bulletins verbatim; it is not treated as a record of Namecheap’s outage. Namecheap has stated explicitly that phoenixNAP is not its datacenter operator, however, some earlier posts on X and Namecheap's status page post incorrectly referred to it.
Timeline of the Outage
phoenixNAP rows are marked [phoenixNAP]. They describe a different company’s incident and are included for the RadiusDC bulletins they carry, not as Namecheap events.
| UTC | Event |
|---|---|
| Aug 13 10:28 | [phoenixNAP] phoenixNAP opens an incident for higher ambient temperature in its Phoenix datacenter |
| 11:28 | [phoenixNAP] phoenixNAP notes equipment may be rebooting during the temperature issue |
| 12:35 | Namecheap publishes its emergency maintenance post - cooling system failure at the Phoenix datacenter, seven service categories affected, helpdesk down, Microsoft Teams accounts offered as a support fallback |
| 13:21 | [phoenixNAP] phoenixNAP's support portal confirmed down, so its customers cannot raise tickets either |
| 14:30 | RadiusDC issues a customer communication about elevated white space temperatures at PHX-01. Note: this time is taken from a later RadiusDC bulletin referring back to it, not from a timestamped publication |
| 14:45 | Chiller D restored, per the same RadiusDC bulletin |
| 16:00 | Namecheap: 2 of 4 chillers back online, temperatures beginning to drop, third chiller anticipated in approximately 3 hours |
| 16:36 | [phoenixNAP] phoenixNAP: some cooling capacity appears to have been restored, no ETA on full resolution |
| 16:58 | [phoenixNAP] phoenixNAP publishes RadiusDC's bulletin in full - elevated temperatures caused by multiple utility bump events attributable to overnight storms, Chiller C restoration targeted for 19:30 UTC, temporary on-floor cooling from approximately 17:00 UTC, an additional temporary chiller and backup generator targeted for approximately 23:00 UTC |
| 18:30 | Namecheap preparing a staged restoration - physical network devices, then virtual network devices, then customer services. Expects to begin in approximately 1 hour |
| 21:30 | Namecheap: core databases, core virtualization, most core network equipment, internal source control and package management, and all major load balancers back online. Namecheap.com, email and hosting are the next phase |
| 22:05 | [phoenixNAP] phoenixNAP reports RadiusDC has restored the third chiller and temperatures are starting to stabilize |
| 22:10 | Namecheap.com and Namecheap Live Chat back online |
| 23:50 | Account access, domains and DNS management restored. More than 50% of Shared Hosting and more than 30% of affected VPS customers back |
| Aug 14 01:34 | Email help system up. EasyWP.com and Dashboard operational, client websites still affected. More than 80% of Shared Hosting, more than 90% of VPS, Dedicated Servers back. Outgoing and incoming mail operational on legacy and new Private Email plans |
| 02:02 | [phoenixNAP] phoenixNAP reports its own services in RadiusDC PHX-01 back online. Note: this update gives the recovery time as 02:03 UTC, whereas its next update at 02:30 UTC gives it as 01:23 UTC. phoenixNAP's page does not reconcile the two |
| 03:00 | EasyWP client sites on two named ALIAS records still unreachable or showing a database connection error. More than 90% of Shared and Reseller Hosting back. All affected VPS packages up |
| 06:10 | [phoenixNAP] phoenixNAP declares all its systems restored and its support operational, effective 06:00 UTC |
| 10:24 | [phoenixNAP] phoenixNAP opens a further incident: Cloud Object Storage unavailable, attributed on its own status page to the cooling issue at the Phoenix facility. This is a little over four hours after phoenixNAP declared all systems restored |
| 17:00 | Namecheap status post marked resolved |
| 17:42 | [phoenixNAP] phoenixNAP moves its Cloud Object Storage incident to Identified, with no ETA. |
Impact window (Namecheap status page): Aug 13 12:35 UTC to Aug 14 17:00 UTC, about 28 h 25 m from the first emergency post to the resolve.
Sources:
- Namecheap status page report. Note that the Namecheap status page report is gone, and the archived version is a partial snapshot, but IncidentHub recorded it when it was available, including the resolution time.
- phoenixNAP status page report.
Impact and Root Cause
The root cause was outside Namecheap's control. Namecheap says only that cooling systems failed at the RadiusDC: Phoenix datacenter - Namecheap's largest - due to a major storm. The additional data comes from a RadiusDC customer bulletin, which reaches the public record through phoenixNAP’s status page. The bulletin attributes elevated temperatures at a Phoenix datacenter to multiple utility events caused by overnight storms in the Phoenix area. The chillers went down with the utility disturbance.
Namecheap's blog describes RadiusDC: Phoenix as a Tier 3 datacenter designed with a high level of redundancy, and calls the incident unusual and unprecedented in its 25-year history.
What Was Taken Offline and Why
The servers were switched off deliberately. Klein's statement puts the number at more than 5,000 servers, and describes the shutdown as a deliberate decision taken to protect customer infrastructure from overheating and longer-term damage. The shutdown decision was probably a reasonable call. The cost was that the outage lasted as long as the cooling did, plus the restoration.
Services Affected
Per the first status post and the CEO statement:
- Namecheap.com and the account dashboard.
- Shared, VPS and Dedicated Hosting, including hosting panel access.
- EasyWP - EasyWP.com, the Dashboard, and client websites.
- DNS management. DNS zone resolution stayed up.
- Private Email, Shared Hosting mailboxes, Free Email Forwarding and Domain Privacy email forwarding.
- URL Redirect management on BasicDNS and PremiumDNS. Redirects continued to resolve.
- Hosting operations - activations, renewals, plan changes - processed with a delay. The blog adds that some billing operations were unavailable after the processing system was taken offline.
- The support helpdesk, live chat and email, with Microsoft Teams accounts offered as a fallback.
The Auctions API and the iOS and Android auction applications were listed as continuing to operate normally.
On email, Namecheap's position from the first post onward was that delivery would be delayed but messages were not expected to be lost, on the basis that sending servers retry. That is correct as a general description of SMTP behavior. However, retry windows are set by the sending server, not the receiving one. Namecheap has not published anything to suggest that mail was in fact lost.
Namecheap Was Not the Only Affected Provider in Phoenix
phoenixNAP published its own cooling-related outage report across the same window, naming RadiusDC as its provider.
Spaceship, Namecheap's web services platform, published its own outage post naming the same RadiusDC: Phoenix facility. Spaceship reported Shared and VPS hosting, EasyWP, email forwarding and Spacemail affected, although Spaceship.com itself stayed online throughout, which Namecheap.com did not.
Hosting.com warned first of elevated ambient temperatures and possible equipment reboots, then later reported an active service outage with impacted servers unavailable, which appears to be related to the same incident.
Namecheap and Spaceship both name RadiusDC: Phoenix, so those two are the same facility on the vendors’ own word. phoenixNAP and Hosting.com are inferred to be the same building from matching dates, city, and failure mode, although Hosting.com does not name RadiusDC.
The Recovery
Restoration was staged, and Namecheap said so in advance at 18:30 UTC: physical network devices, then virtual network devices, then customer services. The blog gives the reasoning afterwards, that hosting and email sit on servers, networks, storage and databases that have to come back in order rather than all at once.
phoenixNAP’s own incident shows a tail longer than its all-clear suggested: it declared all systems restored at 06:10 UTC on August 14, then opened a fresh incident a little over four hours later for Cloud Object Storage, which its status page attributes to the same cooling issue.
The pattern is similar to many outage recoveries IncidentHub covers. Complete recovery takes longer and a customer affected by the long tail reads "fully back online" while their own site is still down.
What Namecheap Says Comes Next
From the blog post:
- A review of the incident, with results to be shared publicly.
- More redundancy across its datacenters, which also include Europe and Asia.
- A commitment to be transparent about what is learned.
Conclusion
Namecheap's outage ran from an emergency post at 12:35 UTC on August 13 to a resolve at 17:00 UTC on August 14, about 28 and a half hours. Namecheap attributes it to a cooling system failure at RadiusDC's Phoenix datacenter following a major storm, and powered down more than 5,000 servers to prevent overheating damage. The mechanism behind the cooling failure - utility disturbances affecting the chillers - comes from a RadiusDC bulletin published on phoenixNAP's status page, not from Namecheap.
DNS zone resolution survived here because it sat outside the failure domain, whereas DNS management did not. Namecheap's blog says the Phoenix facility hosts some essential Namecheap operations, and the list of what broke suggests those operations sit under most of the product line. Namecheap and Spaceship lost services in the same building on the same day.
FAQ
What caused the August 13, 2026 Namecheap outage?
Namecheap attributes it to a cooling system failure at the RadiusDC: Phoenix datacenter in Arizona, following a major storm. A RadiusDC customer bulletin, published on the phoenixNAP status page rather than by Namecheap, attributes elevated temperatures at a Phoenix datacenter to multiple utility events caused by overnight storms in the area. Namecheap powered down affected infrastructure to prevent overheating damage.
How long was Namecheap down?
The emergency maintenance post opened at 12:35 UTC on August 13 and was marked resolved at 17:00 UTC on August 14, about 28 hours 25 minutes. Individual services returned at different times across that window.
Which Namecheap services were affected?
Namecheap.com, Shared, VPS and Dedicated Hosting, EasyWP, DNS management, Private Email and mail forwarding, URL redirect management, hosting operations including some billing, and the support helpdesk. DNS zone resolution and URL redirect resolution continued to work, as did the Auctions API and auction apps.
Was email lost during the outage?
Namecheap said from the first update that delivery would be delayed but messages were not expected to be lost, because sending servers retry when a receiving server is unavailable. That is standard SMTP behavior. Retry windows are set by the sending side, so the guarantee is not absolute, but Namecheap has not reported mail loss.
Were domain registrations at risk?
No. Domain registration records are held at the registry rather than on hosting infrastructure, so ownership was not affected by the datacenter incident. Registrations, renewals and transfers submitted during the window were processed with a delay.
Was phoenixNAP involved?
No. Namecheap states that its datacenter operator is RadiusDC and that phoenixNAP is not involved in the incident. phoenixNAP published an outage report of its own in Phoenix on the same day, naming RadiusDC as its provider. The two reports point towards the same building, but no document from either company confirms it.
Were other providers affected?
Spaceship, Namecheap's web services platform, published its own outage post naming the same RadiusDC: Phoenix facility. phoenixNAP and Hosting.com both reported Phoenix DC problems, although the latter does not name RadiusDC. Even though the individual outage report timelines point towards the same DC, neither Namecheap nor those companies published anything confirming a shared facility with each other.
IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders. This summary is independent and not affiliated with or endorsed by Namecheap, Spaceship, RadiusDC, phoenixNAP or any of the services and vendors mentioned in this article.
This article was first published on the IncidentHub blog.
You might also like: