INCIDENT RESOLVED — updated 14 August 2026
RESOLVED — 14 August 2026, 17:00 UTC. Namecheap has declared the incident closed. All hosting, EasyWP, DNS, Private Email and support services are back online after 30 hours 32 minutes.
The cause was a major storm that knocked out cooling at the RadiusDC Phoenix data center. RadiusDC instructed Namecheap to power services down to protect hardware. Namecheap reports no data loss and says it will add redundancy across its US, European and Asian data centers. Full timeline and updates below.
Websites, business email, and DNS for a large slice of Namecheap's customer base went dark on 13 August 2026 after the cooling system at the Phoenix data center hosting the company's core infrastructure failed. By Namecheap's own count, more than 5,000 servers were taken offline — not by the failure itself, but by a deliberate shutdown to stop hardware cooking in a data hall that had lost its chillers.
The blast radius is wider than that of most outages at a hosting provider because Namecheap's authoritative DNS servers sit within the same failure domain. That means sites hosted elsewhere broke too, as long as their nameservers pointed to Namecheap. And because the support helpdesk lives in that same building, customers could not open a ticket to ask what was happening.
What Is Actually Broken
Namecheap's status post explicitly lists the affected services. This is the full scope as the company described it:
| Service | Reported impact |
|---|---|
| namecheap.com | Site under emergency maintenance; account dashboard unreachable |
| Shared, VPS & Dedicated hosting | Sites unavailable, slow, or returning 503 errors; cPanel/hosting panel inaccessible |
| Namecheap DNS | Zone resolution and zone management unavailable |
| EasyWP | Entire platform affected — EasyWP.com, the dashboard, and customer sites |
| Private Email | Intermittent; incoming and outgoing delivery both disrupted |
| Mail forwarding | Free Email Forwarding and Domain Privacy forwarding both hit |
| URL Redirect | Affected on both BasicDNS and PremiumDNS |
| Support helpdesk | Unable to process email tickets; live chat pushed as the fallback |
| Hosting operations | Activations, renewals, and plan changes are being processed with delays |
One detail from the original advisory went largely unreported: with both live chat and email ticketing down, Namecheap moved customer support to Microsoft Teams, publishing a list of backup Teams accounts split by department — separate handles for domains, hosting, SSL, transfers, managed WordPress, Private Email, billing and abuse. It was an improvised channel for an outage that had taken out the normal ones, and most customers never saw it because the page announcing it was itself hard to reach.
Independent outage trackers put the user-reported breakdown at roughly 60% hosting, 30% domains, and 10% cloud services, with reports arriving from Mexico, Vietnam, Uruguay, and across Europe — consistent with a single-origin failure rather than a regional network problem. Live user reports are aggregated on Downbits' Namecheap status page, which also lets you file a report if your own services are affected.
Timeline of the Namecheap Outage
All times below are UTC, with Indian Standard Time in brackets. The sequence matters because the data center operator flagged the problem roughly two hours before Namecheap told customers anything.
| Time | Event |
|---|---|
| 10:28 UTC (15:58 IST) | PhoenixNAP opens an incident titled “Higher ambient temperature in the Phoenix DC”, noting no critical service impact |
| 11:28 UTC (16:58 IST) | PhoenixNAP moves the incident to Identified, warning that the equipment may reboot |
| 11:42 UTC (17:12 IST) | Namecheap posts a separate notice about EasyWP servers being unreachable |
| ~12:20 UTC (17:50 IST) | Third-party trackers register the start of mass user reports |
| 12:35 UTC (18:05 IST) | Namecheap publishes its emergency maintenance status post, citing a power outage |
| ~12:40 UTC (18:10 IST) | Namecheap confirms the disruption on X; states there is no ETA |
| 13:04 UTC (18:34 IST) | PhoenixNAP reports its facilities team is working with an on-site vendor, still no ETA |
| Later, 13 Aug | CEO Hillan Klein states 2 of 4 chillers are back, temperatures are dropping, and a third is expected within roughly three hours |
| 21:30 UTC (03:00 IST, 14 Aug) | Status page confirms core databases, core virtualisation, most core network equipment, internal source control and all major load balancers back online |
| 22:10 UTC (03:40 IST, 14 Aug) | Namecheap.com and Live Chat back online — 11 hours 42 minutes after the first data centre alert |
| 23:50 UTC (05:20 IST, 14 Aug) | Account access, domains and DNS management restored. Shared hosting past 50%, VPS past 30%, dedicated servers returning. Email still down, no ETA |
| 01:34 UTC, 14 Aug (07:04 IST) | Email help system up. Private Email sending and receiving operational on legacy and new plans. Dedicated servers fully back. VPS past 90%, shared hosting past 80%. EasyWP.com and Dashboard operational, client websites still affected |
| 03:00 UTC, 14 Aug (08:30 IST) | All affected VPS packages up and running. Shared and reseller hosting past 90%. Many EasyWP client sites accessible; sites on two named ALIAS records still affected |
| 07:50 UTC, 14 Aug (13:20 IST) | All EasyWP services up. Shared and Reseller Hosting fully back online. Namecheap begins reviewing all services |
| 09:05 UTC (14:35 IST) | MySQL stopped for maintenance on Premium Server 126 and Premium Server 247; sites on those hosts show database errors. Window given as 4–6 hours per host |
| 12:55 UTC (18:25 IST) | Some VPS and dedicated servers found still unreachable or returning 503 errors; VPS investigated globally, dedicated case by case |
| 13:19–13:34 UTC (18:49–19:04 IST) | MySQL recovered on both Premium Servers, with no data loss |
| 15:15 UTC (20:45 IST) | All affected VPS Hosting packages back online |
| 17:00 UTC (22:30 IST) | Namecheap declares the incident resolved — 30 hours 32 minutes after the first data centre alert |
How Long Was Namecheap Down?
For the main site, 11 hours 42 minutes — from PhoenixNAP's first temperature alert at 10:28 UTC on 13 August to Namecheap confirming namecheap.com back online at 22:10 UTC. Measured from Namecheap's own first customer notice at 12:35 UTC, it is 9 hours 35 minutes.
End to end, the incident ran 30 hours 32 minutes — from 10:28 UTC on 13 August to Namecheap declaring it resolved at 17:00 UTC on 14 August. Measured from Namecheap's own first customer notice, 28 hours 25 minutes.
Recovery was staggered, so no single number describes what any given customer experienced. Live Chat was unreachable for roughly ten hours. Namecheap.com returned at 11 hours 42 minutes. EasyWP client sites took until 07:50 UTC on 14 August. Some VPS and dedicated servers were still unreachable at 12:55 UTC, more than 26 hours in, and shared hosting customers on two Premium Servers hit a fresh database outage on the second day. If you need a figure for an SLA claim, use your own monitoring timestamps rather than any headline number.
Restoration Progress by Service
| Service | Status |
|---|---|
| namecheap.com | Online since 22:10 UTC. Account access, domains and DNS management restored |
| Live Chat | Online since 22:10 UTC |
| Email help system | Up and running — ticket submission working again |
| Dedicated Servers | Back online |
| VPS Hosting | All affected packages up and running |
| Shared Hosting | More than 90% back online |
| Reseller Hosting | More than 90% back online |
| Private Email | Outgoing and incoming delivery operational on legacy and new plans (Launch, Scale, Expand). Outage-period mail may still arrive delayed |
| EasyWP | Partly affected. EasyWP.com and Dashboard fully operational, many client sites accessible. Sites on two specific ALIAS records still down |
| Spaceship VPS, Shared & Spacemail | Back online |
Everything in the table above is now restored. Recovery ran roughly in inverse order of abstraction: raw dedicated hardware and VPS returned first, shared and reseller hosting followed, and EasyWP — the most heavily managed platform, with the most layers between customer and metal — came last, in two stages.
EasyWP Database Connection Errors Explained
EasyWP recovered in two stages, and the gap between them confused a lot of customers. EasyWP.com and the Dashboard came back at 01:34 UTC while client websites were still down — so people logged in, saw their site listed as running, loaded the domain, and got nothing.
At 03:00 UTC Namecheap did something unusually specific: it named the exact infrastructure still affected. Sites pointed at these ALIAS records were the ones returning Error establishing a database connection:
| ALIAS record | Resolves to |
|---|---|
| ingress-baronn.ewp.live | 63.250.43.9 | 63.250.43.10 |
| ingress-cinna.ewp.live | 63.250.43.11 | 63.250.43.12 |
All EasyWP services were confirmed fully restored at 07:50 UTC on 14 August. If your EasyWP site is still unreachable now, it falls outside what Namecheap has described and is worth a ticket rather than self-diagnosis.
Two separate MySQL incidents followed on shared hosting: Premium Server 126 and Premium Server 247 had MySQL stopped for maintenance at 09:05 UTC, with sites on those hosts showing database errors for several hours. Both recovered by 13:34 UTC, and Namecheap confirmed no data was lost in either case.
- Do not restore from a backup. Your files and database are almost certainly intact; the serving layer is what is missing. A restore solves nothing and risks overwriting good data with older data.
- Do not delete and recreate the site from the dashboard.
- Do not repoint DNS away from EasyWP mid-restoration. You will chase propagation for hours on a site that would have come back on its own.
- Do not reinstall plugins or WordPress core to fix a site you cannot reach.
Restoring from a backup during that window was the single worst thing an affected owner could have done. A database connection error means the database layer is unreachable, not that data is damaged — a restore would have overwritten intact data with older data for no benefit.
What Actually Caused the Namecheap Outage
During the incident Namecheap gave customers two different causes, and the discrepancy went uncorrected for more than a day. Its post-incident communication finally reconciled them.
One naming note worth clearing up first, because coverage has split on it. The facility is the same building under two names: RadiusDC acquired PhoenixNAP's Phoenix data center and colocation business in a deal announced on 12 March 2026, with the site becoming RadiusDC's Phoenix I campus and PhoenixNAP remaining as a tenant. That is why PhoenixNAP's own status page logged the same ambient-temperature incident while Namecheap's communications name RadiusDC. There is no indication the ownership change contributed to the failure.
The status post and the company's X account both attribute the incident to “emergency maintenance due to a power outage affecting our datacenter in Phoenix”.
Namecheap CEO Hillan Klein, posting publicly the same day, described something different: an infrastructure incident at PhoenixNAP where “the facility has suffered a failure of its cooling systems”. He said Namecheap then chose to power services down to prevent overheating and long-term hardware damage.
PhoenixNAP's own status page supports the CEO's version, not the status post's. Its incident is titled around ambient temperature, and its updates describe chillers and a cooling vendor — there is no mention of a utility power failure.
Namecheap's post-incident communication settled it. A major storm knocked out cooling at the RadiusDC Phoenix facility, driving temperatures to unsafe levels. That reconciles both accounts: a storm-driven power event took the chillers down, and the chiller loss forced a thermal shutdown.
Two details from that account correct what was reported during the incident, including here. First, the decision to power down was not Namecheap's own call — RadiusDC instructed Namecheap to take services offline to protect customer infrastructure. Second, staying offline until conditions were safe was itself part of the recovery strategy, not just a consequence of the failure.
The distinction between a power outage and a cooling failure was never academic. A power outage implies infrastructure that returns when the lights do. A thermal shutdown is slower, because you cannot safely repower thousands of servers until the hall has actually cooled. That is why this ran for a day and a quarter rather than minutes.
Namecheap's status post was also quietly revised. It originally attributed the incident to a power outage; the current version describes a cooling failure. No correction notice was attached to the change.
No, There Is No Confirmed DDoS Attack
Several outlets and aggregator sites have published headlines pairing this outage with a distributed denial-of-service attack. Some framed it as Namecheap being hit by a DDoS and a power outage simultaneously.
Cyber Kendra checked every primary source available for this incident: Namecheap's status post, its X account, its CEO's public statement, and PhoenixNAP's status page. None of them mentions a DDoS attack. Every official account points to a facility-level cooling or power problem.
The DDoS framing appears to be a carryover from a separate Namecheap incident in February 2024, when the company confirmed a DDoS affecting its main site and support systems. It has also experienced DDoS-related disruption on a dedicated server earlier in 2026. Those were real events. They are not this one.
Some customers on social platforms have alleged that Namecheap initially communicated a DDoS before switching to the power-outage explanation. Cyber Kendra has not been able to verify that claim against any archived Namecheap communication, and it should be treated as unconfirmed. If you are reading a report that attributes this outage to an attack, check whether it cites a Namecheap source or another news article.
Will I Lose Email, Files, or Data?
On email, Namecheap has been specific, and the explanation is technically sound. Mail sent to affected addresses during the outage is not expected to be lost. When a receiving mail server is unreachable, the sending server queues the message and automatically retries over a period that can last for days. Once connectivity returns, the backlog delivers. What you should expect is delay, not loss.
The exceptions worth knowing:
- Senders whose mail servers give up early, or which bounce on the first timeout, may generate a delivery failure notice. Those messages will not arrive on their own.
- Anything time-sensitive that routed through Namecheap forwarding — password resets, OTPs, payment confirmations, calendar invites — may arrive too late to be usable, even if it eventually arrives.
- Mail you were composing in webmail at the moment of the cutoff is gone unless it was saved as a draft on the server.
My Namecheap inbox is empty. Are my old emails gone?
As services returned, multiple users reported logging into webmail successfully and finding their mail missing. One asked CEO Hillan Klein publicly whether a day of incoming mail was simply gone, then confirmed after his reply that login and iOS access worked normally while nothing arrived.
Klein's answer at the time was that email services were not fully back and mail would be restored once the remaining infrastructure came up. That is what happened. A staged restart brings authentication and webmail front-ends back before the mail storage behind them, so a login succeeds against a mail store that is not yet online and presents as an empty inbox. It was not deleted mail. Private Email is now sending and receiving on both legacy and new plans.
If your mailbox still looks wrong:
- Give it time. Namecheap says outage-period mail may still be delayed, and queued backlogs from external senders deliver over hours, not seconds.
- Do not delete and re-add the account in Outlook, Thunderbird or Apple Mail while a backlog is landing — your client's local cache may hold the most complete copy.
- If you use POP3 without leaving copies on the server, your local store is the authoritative copy. Back it up before touching anything.
- Shared hosting mailboxes are separate from Private Email. If your hosting is in the remaining percentage, your mail is too.
- If mail is still missing once the backlog settles, raise a ticket — the email help system is working again.
What about my website data?
On hosting data, a thermal shutdown is a controlled power-down, which is the safest kind. Namecheap has not reported data loss and has not indicated that any storage was damaged. That said, an unplanned shutdown of thousands of machines can leave individual databases in an inconsistent state on restart. When your site comes back, check that recent writes — orders, form submissions, new posts — are actually present before assuming everything restored cleanly.
What Namecheap Users Should Do Right Now
- Do not start a domain transfer yet. Transfers need working registrar systems and a reachable admin email. With mail backlogs still clearing, an auth code or approval message can arrive late enough to stall the transfer.
- Do not change nameservers in a panic. A half-applied nameserver switch during propagation can extend your downtime well past the outage itself.
- Support is working again. Email ticketing was down for most of the incident and live chat was the only channel. Both are restored, so a ticket is now the better route for anything needing a paper trail — particularly an SLA credit request.
- Tell your own customers before they tell you. If you host client sites, a short factual notice naming the upstream cause protects you far better than silence. Link to the vendor status page, not to your own guesswork.
- Screenshot everything. Uptime monitor logs, error pages, timestamps, and lost transaction records. If you intend to ask for a credit, the case is built on evidence you collect now, not on your recollection next week.
- Check your recent data once you are back. Verify the last few hours of database writes before the outage, and confirm scheduled jobs and cron tasks resumed.
The Design Decision That Made This Worse
Most coverage of this outage stops at “data center had a problem”. The more useful question is why a single facility could take out this much surface area at once.
Namecheap has been a major tenant of the same Phoenix building for years, first under PhoenixNAP and now under RadiusDC. In its own public post-mortem after a 2018 outage at the same facility, the company described itself as one of the site's largest tenants, drawing around half a megawatt and running thousands of servers there. The 5,000-plus figure cited this week suggests that concentration has not meaningfully changed.
Concentrating hosting in one well-run facility is a defensible business decision. Concentrating authoritative DNS in the same failure domain as the hosting it serves is a different matter. DNS is the one service in the stack that is supposed to be geographically distributed precisely so that it survives the loss of any single site. When Namecheap DNS went down, it did not just break Namecheap-hosted sites — it broke every site anywhere in the world whose nameservers pointed at Namecheap, including sites hosted on entirely unaffected providers.
The support helpdesk sitting in the same building compounds the problem. The moment customers most needed to reach Namecheap was the moment Namecheap could not receive tickets. Status communication then falls back to X, which is not where most customers look first.
For readers who host with Namecheap, the practical takeaway is narrower than “switch providers”. It is this: your DNS provider and your hosting provider should not be the same company on the same site. Moving authoritative DNS to an independent, anycast provider costs nothing on most free tiers and decouples the two largest failure modes you are exposed to. Had that separation been in place, a large share of the sites that broke this week would have remained resolvable, served an error from their origin, and been fixable with a temporary redirect.
Namecheap's Track Record at Phoenix
This is not the first significant incident at the same facility, and the pattern is part of why the reaction from longtime customers was so sharp.
- November 2018 — A power failure at PhoenixNAP during UPS maintenance caused route flapping on Namecheap's core network. The company published a detailed post-mortem noting that some non-critical infrastructure was not designed to be power-redundant.
- August 2020 — A prolonged outage hit namecheap.com, shared hosting, VPS, EasyWP, and Private Email; Namecheap ultimately attributed it to a third-party upstream provider.
- September 2021 — A misconfiguration during network expansion triggered a network storm that took down a redundant firewall cluster. Namecheap's post-mortem conceded that its first response had been based on an incorrect assumption, costing it hours.
- February 2024 — A confirmed DDoS campaign affected the main site and customer support.
- July 2026 — Shared and VPS hosting in Phoenix experienced timeouts, with restoration staged across servers.
Read together, these are not all the same failure. But four of the five involve the Phoenix footprint, and the recurring theme in Namecheap's own post-mortems is redundancy that existed on paper failing to hold at the edges.
What Namecheap Says It Will Change
In the email sent to customers after resolution, Namecheap committed to examining the incident in detail and adding further redundancy across its data centers in the US, Europe and Asia. It also said it would publish what it learns and the actions it takes.
That is the right response to this failure mode, and it is worth holding the company to. The problem this outage exposed was not that a data center failed — data centers fail — but that too much sat in one of them, including services like authoritative DNS that exist specifically to survive the loss of any single site. Geographic redundancy across three continents addresses exactly that, if it is implemented for DNS and not only for hosting.
Namecheap published detailed post-mortems after its 2018 and 2021 incidents. Whether a comparable document follows this one is the thing to watch, and Cyber Kendra will update this page when it appears.
Can You Claim Compensation?
Namecheap had not announced any compensation, service credit, or SLA payout at the time of writing, and customers were publicly asking for one.
What is worth knowing before you ask: hosting SLA credits generally have to be requested rather than applied automatically, are usually calculated as a proportion of the monthly fee rather than your business losses, and are typically defined in the hosting terms rather than the general terms of service. Read the SLA terms attached to your specific plan — shared, VPS, dedicated, and EasyWP are not necessarily covered identically — and file the request through the ticket system once it is processing email again, with your monitoring logs attached.
Cyber Kendra is not a legal advisor, and consequential losses from downtime are usually excluded by hosting contracts. If the sums involved are material to your business, that is a conversation for a lawyer rather than a support ticket.
Frequently Asked Questions
Is Namecheap down right now?
Almost fully restored. Namecheap.com, Live Chat, the email help system, DNS management and Private Email are back. All affected VPS packages are running, dedicated servers are restored, and shared and reseller hosting are past 90%. Some EasyWP client websites remain affected. Namecheap has not declared the incident fully resolved. For crowd-sourced reports from other users, see Downbits.
Why is Namecheap down?
A major storm knocked out cooling at the RadiusDC Phoenix data center, driving temperatures to unsafe levels. RadiusDC instructed Namecheap to take services offline to protect hardware, taking more than 5,000 servers down. The facility was acquired from PhoenixNAP earlier in 2026, which is why both names appear in coverage.
Was Namecheap hacked or hit by a DDoS attack?
No primary source from Namecheap or PhoenixNAP describes an attack for this incident. Reports linking it to a DDoS appear to conflate it with a separate, confirmed February 2024 Namecheap incident.
Will I lose emails sent during the Namecheap outage?
Namecheap says messages are not expected to be lost. Sending mail servers queue and retry automatically, so mail should deliver late rather than disappear. Hard bounces from senders that give up early are the exception.
Why is my Namecheap email inbox empty after the outage?
Email infrastructure was restored in stages, so webmail login returned before the mail storage behind it. That produced mailboxes that opened but appeared empty. Private Email is now sending and receiving on both legacy and new plans, though outage-period mail may still arrive delayed.
How long was Namecheap down?
30 hours 32 minutes end to end, from the first data centre alert at 10:28 UTC on 13 August to Namecheap declaring resolution at 17:00 UTC on 14 August. The main site itself was unreachable for 11 hours 42 minutes; EasyWP and some VPS and dedicated servers took considerably longer.
My EasyWP site shows “Error establishing a database connection”. Why?
Because your site sits on one of two ingress groups Namecheap has confirmed are still affected: ingress-baronn.ewp.live (63.250.43.9, 63.250.43.10) and ingress-cinna.ewp.live (63.250.43.11, 63.250.43.12). Run a DNS lookup on your domain to check. If it resolves to one of those addresses, it is a Namecheap-side problem — do not restore from backup, recreate the site or repoint DNS.
Are my domain registrations at risk?
Domain registration records are stored at the registry, not on Namecheap's hosting servers, so ownership is unaffected by a data center outage. Renewals and transfers processed during the window may be delayed.
My site is hosted elsewhere, but it still went down. Why?
Because your domain's nameservers point at Namecheap DNS. Namecheap's authoritative DNS was in the same failure domain as its hosting, so name resolution failed regardless of where the site was served.
Should I move my domain away from Namecheap?
Moving registration mid-incident is more likely to create problems than solve them. The higher-value change, once services are stable, is to separate DNS from hosting so that a single provider outage cannot break both at once.
Updates
2026-08-14, 17:00 UTC — Resolved. Namecheap declared the incident closed, 30 hours 32 minutes after the first data centre alert. Cause confirmed as a major storm knocking out cooling at the RadiusDC Phoenix data center, with RadiusDC instructing Namecheap to power services down. No data loss reported. Namecheap has committed to adding redundancy across its US, European and Asian data centers. No compensation announcement; no post-incident report yet.
2026-08-14, 15:15 UTC — All affected VPS Hosting packages back online.
2026-08-14, 07:50 UTC — All EasyWP services restored. Shared and Reseller Hosting fully back. Separate MySQL maintenance on two Premium Servers followed, recovered by 13:34 UTC with no data loss.
2026-08-14, 03:00 UTC — All affected VPS Hosting packages up and running.
2026-08-13 — Article published during the active outage.
This page is updated as the incident progresses. Bookmark it rather than searching again.
Disclosure: Downbits, linked above, is operated by Cyber Kendra.