On the morning of 13 August 2026 the chillers stopped working at a data center in Phoenix. By the end of the day Namecheap had deliberately powered down more than 5,000 servers to keep them from cooking, and a real slice of the internet went with them: websites, business email, DNS, and the support desk you would have used to ask about any of it. Here is what actually happened, where the story kept changing, and what it should change about how you hold your own domains.
What actually happened
Namecheap does not own the building. Its US infrastructure is colocated at phoenixNAP, in a relationship that goes back more than a decade. Overnight storms caused repeated utility power interruptions at the site, and those interruptions took out the chillers - the industrial cooling plant that keeps a data hall from turning into an oven.
The important nuance, and the one most coverage skipped: the outage customers experienced was not a hardware failure. It was a controlled shutdown. Once the room temperature started climbing, Namecheap chose to pull the power on its own equipment rather than let it run hot and risk permanent damage. That was almost certainly the right call. Silicon that has been cooked does not come back at 3am, and a day of downtime is cheaper than a fleet of dead disks.
It also was not only Namecheap. Liquid Web opened its own critical incident at the same facility with the same cause, which tells you this was a building-level event rather than something Namecheap did to itself.
phoenixNAP opens an incident for higher ambient temperature in the Phoenix data center. Storms overnight had caused a series of utility power interruptions that knocked out the building chillers.Single-sourced. phoenixNAP’s own incident history could not be retrieved.
Namecheap posts its emergency notice. As published, it reads: “We’re currently responding to an emergency caused by a power outage at our Phoenix datacenter.”
The @Namecheap account on X also blames a power outage. That post was never corrected.
CEO Hillan Klein posts the first detailed account. It is not a power outage. It is a cooling failure, and Namecheap chose to power down more than 5,000 servers to stop them cooking. This is also the post containing the email assurance.
Two of four chillers are back. This is the first status update in three hours and twenty five minutes, straight through the US morning peak.
An archived capture shows the status page still saying “power outage,” more than an hour after the CEO said otherwise.
Somewhere in this window the status page is silently rewritten. “A power outage” becomes “a failure of cooling systems.” The byline still reads 08:35 AM. No changelog, no correction, no note that anything changed.
Klein lays out a three stage restoration and targets 3:00 to 3:30pm ET for customer services coming back.
Namecheap.com and live chat return, roughly nine and a half hours after the emergency notice and nearly three hours past the target.
Private Email is declared operational, incoming and outgoing, on both the legacy and the newer plans.
Klein apologises: “We failed you today.” A post-mortem is promised.
Full restoration.
How long was it? Depends where you start the clock, and the reporting does not agree. TechRadar said about 15 hours. Namecheap’s own status updates span roughly 19 hours 15 minutes from the emergency notice to the all clear. Measured from phoenixNAP’s first temperature alert it is closer to 21 hours 20 minutes. Pick whichever you like, but show your work - a single confident number here is someone rounding in their own favour.
How big the hole was
Namecheap named the affected services itself. The list is long enough that it is easier to describe what a customer had left, which was mostly nothing:
- Namecheap.com, plus the account dashboard
- Shared, VPS, Dedicated and Reseller hosting
- EasyWP
- DNS
- Private Email and hosting email, free email forwarding, and Domain Privacy email forwarding
- URL Redirect, on both BasicDNS and PremiumDNS
- The support helpdesk itself - live chat and email ticketing both down
Read that last one again, because it is the sharpest detail in the whole incident. The knowledgebase article explaining how to email support lived on namecheap.com, which was down, so the instructions for reaching support during an outage were themselves inside the outage. The official fallback was Microsoft Teams. When your escape hatch is bolted to the room you are trying to escape, you do not have an escape hatch.
One more thing worth naming, because people kept getting it wrong: Jellyfish is not a hosting platform. It is Namecheap’s machine-learning mail filtering and management tier, sitting in front of Private Email, shared hosting mail, EasyWP, forwarding, and Spaceship’s Spacemail. That is why customers kept naming it in the same breath as Private Email. It is a shared, cross-brand mail layer, and it was in the same building as everything else.
The DNS question, which nobody can actually answer
This is the one that decides whether the blast radius stopped at Namecheap’s customers or reached anyone whose nameservers pointed there. And the honest answer is that it is unresolved, partly because Namecheap told two different stories.
Early captures of the status page say: “Namecheap DNS infrastructure is unavailable. DNS zone resolution and management are affected.” Later captures say: “DNS zone resolution is available. DNS Management is affected.” Those are materially different claims. The first means domains stopped resolving. The second means they kept resolving and you just could not change them. No independent measurement - no resolver telemetry, no RIPE Atlas data - appears to exist publicly to settle it. Several outlets asserted the harsher version as fact. They were most likely reading the earlier wording.
The story kept changing
The technical failure was bad luck in a building Namecheap does not own. The communication was a choice, and it is where most of the anger came from.
For at least four and a half hours, and probably closer to six, Namecheap’s official written position was that this was a power outage. The status post said so. The @Namecheap account on X said so. Then at 15:56 UTC the CEO said it was a cooling failure, which contradicted both, and the status page went on saying power outage for another hour after that. Klein later put the discrepancy down to miscommunication from the data center.
What happened next is the part that matters. Sometime between 17:02 and 18:25 UTC, the status post was edited in place. “An emergency caused by a power outage at our Phoenix datacenter” became “an emergency caused by a failure of cooling systems.” The byline still read 08:35 AM. There was no changelog, no strikethrough, no note acknowledging a correction. Anyone arriving after the edit would read a post that appeared to have said the right thing from the beginning. The only reason we know is that the Internet Archive captured the page on both sides of the change. The X post was never corrected at all.
Customers noticed the shifting story in real time, and a sharper accusation started circulating - that an earlier status post had blamed a DDoS attack and had then been quietly removed.
Not buying any of it. Your 8:03 status post said Private Email and Jellyfish were under DDoS. That post is gone. If it got merged into the power outage notice, say so, so far it looks like a security incident is being masqueraded as a “cooling incident”.
This deserves care, so here is exactly what stands up and what does not. Something real is missing: the third-party monitor StatusGator independently logged a Namecheap status entry titled “Temporary Technical Issues with the Private Email and Jellyfish services,” severity Down, lasting 13 hours 40 minutes. That entry is not in Namecheap’s status archive today. NetBlocks also reported at the time that the company had cited both a DDoS and a power outage.
What does not stand up is the specific wording. No primary artifact containing the word DDoS survives. Searches of the archived status index return zero hits for it. And the Internet Archive has a roughly 13-hour capture gap that lands squarely over the alleged 08:03 post, so the record can neither confirm nor refute it. The defensible reading is that a Private Email and Jellyfish status entry demonstrably existed and is demonstrably gone, that the DDoS framing demonstrably circulated and was sourced to Namecheap, and that the exact wording of the removed post is not something anyone can currently prove. Namecheap has not addressed it.
Underneath the forensics was a simpler complaint. People running real businesses on top of this could not tell their own customers anything.
I have more than 700 websites down and clients are mad with us because we have several ecommerce runing there, please provide status reports
The update cadence did not help. Working from Namecheap’s own timestamps, there were nine updates across about 20 and a half hours, unevenly spaced, with a three hour twenty five minute silence through the morning peak and a four hour fifty minute gap overnight. The two worst gaps bookended the incident. Meanwhile the ETAs kept slipping: the third chiller was “approximately 3 hours” away at noon, services were “approximately 1 hour” away at 2:30pm, and the CEO publicly targeted 3:00 to 3:30pm. The website came back at 6:10pm and email at 9:34pm.
It’s 90 minutes past the 3pm est that I was expecting after your three hour notice seeing restoration. I just lost a deal that was significant a contract for my small business because I miss the meeting. That was the kickoff. My email is down my two webpages are down.
Fact-check: what the CEO said about email
This is the claim worth pinning down, because it was widely paraphrased as “the CEO said email would work,” and that is not what he said. Here is the actual sentence, from Klein’s 15:56 UTC post:
Hillan Klein · 13 Aug, 15:56 UTC
“For email specifically, delivery may be delayed, but messages are not expected to be lost. Sending servers should retry once connectivity is restored.”
Namecheap’s status page carried near-identical language from 08:35 ET, adding that sending servers would see connection timeouts. The verdict: substantially accurate on the narrow mechanical claim, but incomplete and over-reassuring. Four points.
One, he never claimed email was working. In the same post he listed Private Email, hosting email and email forwarding among the affected services. Anyone quoting him as promising email would work is misquoting him. He promised mail would not be lost, which is a much narrower thing.
Two, the mechanism he described is correct. When a receiving mail server is unreachable, a well-behaved sender queues the message and retries, typically for days. Private Email was down for about 13 hours 40 minutes, comfortably inside any normal retry window. For inbound mail from major providers, “delayed, not lost” was the reasonable expectation.
Three, it left out the direction that retries cannot save. Outbound was dead too. Jellyfish handles outbound filtering, and Namecheap did not declare outgoing delivery operational until 01:34 UTC. Somebody else’s retry queue does nothing for the mail you were never able to send. Every password reset, order confirmation and alert your systems tried to push out during those hours simply did not go.
All my transactional emails to my customers are failing, they depend on notifications for safety alerts. Please keep us updated on when service will return.
Four, nobody has confirmed it after the fact. It was a forward-looking prediction made about three hours in, about how other people’s mail servers would behave. No retrospective statement confirming the queues actually drained appears to exist. Nor is there public evidence either way on the question that matters most - whether senders got soft deferrals and retried, or hard rejections and gave up. No bounce messages or SMTP status codes from the incident surfaced anywhere. At least one customer publicly said they had lost all their inbound mail; Namecheap replied that incoming servers were still coming up. Some reports of empty mailboxes were traced to staged restoration, where webmail login came back before the storage behind it.
So: defensible, probably right for most inbound mail, and beside the point for a lot of people. Mail that arrives 13 hours late is not lost, but a one-time passcode that arrives 13 hours late is. That gap between technically-true and practically-useless is where the anger lived.
What Namecheap got right
Worth saying plainly, because the pile-on obscured it. Klein posted five detailed, specific updates over about ten and a half hours under his own name. He named the facility instead of hiding behind “a third party provider.” He explained the shutdown decision and the reasoning behind it. He gave a staged restoration plan rather than a vague reassurance. And when it was over he wrote “We failed you today. We know that trust is earned through our actions, not our words, and we will work every day to regain the trust we lost,” and committed to a post-mortem covering what led to it and where existing safeguards failed.
That is a better standard than most companies manage. It also did not satisfy people, because the thing customers wanted was not eloquence.
This is unbelievable, 6 hours of downtime and counting…. How could an ISP of this size not have a backup for a down data center? This should be disqualifying for whoever is in charge… Moving all my hosting away from namecheap forever.
As of writing, that post-mortem has not been published. Until it is, every architectural question here stays open. Worth noting too that the SLA is less generous than it sounds: the shared hosting guarantee is 100% monthly uptime, but the remedy is one extra day of service per hour of downtime, capped at a month, and only if you file a billing ticket within 10 days. It is not cash, and the terms exclude acts of God. A storm taking out a third party’s chillers is exactly the kind of event that clause exists for. Namecheap has not said whether it will invoke it.
Domain resilience: what you can actually do
The lesson here is not “Namecheap is bad.” Every provider has a bad day, and this one was triggered by weather in a building they rent. The lesson is concentration. Most of their customers had four separate things in one failure domain without ever deciding to. Practical steps, roughly in order of effort:
- Separate the four things you probably think of as one. Your registrar, your authoritative DNS, your hosting and your email are four different services. Buying them from one vendor is convenient and gives you a single blast radius. At minimum, move DNS and email off the registrar.
- Run secondary DNS at a second provider. This is the cheapest large win available. Two providers, both authoritative for your zone, kept in sync by zone transfer or dual-primary. If one disappears, resolvers use the other and nobody notices. Most managed DNS providers support this and several do it free at small scale.
- Add a backup MX, or a relay that queues for you. Klein was relying on the good manners of every sending server on the internet. Mostly that works. A secondary MX on different infrastructure means you are not relying on it, and mail lands somewhere you control.
- Break the circular dependency. If your registrar account recovery address is you@yourdomain.com, and that domain’s email is hosted by that same registrar, a single outage locks you out of your mail and out of the account you would use to fix it. During this incident people could not receive the one-time codes they needed to log in elsewhere. Put your recovery address on a different provider entirely.
- Keep an offline mail archive. An IMAP sync to a local client costs nothing and means that when the mailbox is unreachable you can still see who was trying to reach you and what they wanted. Several people spent the day unable to answer that question about their own customers.
- Lower TTLs before you need them. A 24-hour TTL is fine until the day you need to move a record in a hurry. Know what yours are. Keep your auth codes and registrar contacts somewhere that is not the system that is down.
- Do not host your status page or support channel inside the thing they describe. Namecheap’s status page kept publishing, which is the part they got right. The support desk did not, and the article explaining how to reach support sat on the dead domain. Both belong on a different domain, different DNS, different provider from the thing they are meant to explain.
- Read the actual remedy in your SLA now, while you are calm. “100% uptime guarantee” and “we will refund you for downtime” are not the same sentence, and the second one is usually not what is written.
- Then rehearse it. Blackhole your provider’s nameservers and see what still resolves. Block your mail host and watch where the bounces go. A dependency you have never tested failing is a dependency you do not understand.
The part that should worry you
Namecheap did not do anything exotic here. They put their infrastructure in a reputable data center, ran there for more than a decade, and then the weather took out the cooling. The failure was not carelessness. It was concentration - hosting, DNS, mail, the corporate site and the support desk all sharing one physical dependency, so a single building took out both the service and most of the channels for talking about the service.
That shape is extremely common, and most organisations have never drawn it out. It is worth finding out what your own version looks like before somebody else’s chillers find out for you.
Business continues, even when access does not
Namecheap’s customers lost their sites, their mail and the helpdesk they would have used to ask about it, all at the same time. That is precisely the scenario continuity planning exists for. Jestr maps these dependencies for enterprises and rehearses the outage before it happens, so the business keeps running when a vendor goes dark.
Request early access