What Q3 2026 Outages Teach a One-Site Business

The biggest lesson from the Q3 2026 outages is simple: many of them were caused by one physical thing failing in one place, such as a cooling system, a power feed or a fiber cable. You cannot stop those failures, but you can make sure one of them does not take your website, your domain and your email down at the same time.

Here is the fact that made me write this. On 13 August 2026, according to Cloudflare Radar, a cooling system failure at a single data center in Phoenix, USA caused a near-total drop in traffic from Namecheap's network (AS22612). Four weeks later, on 10 September, a power failure at one interconnection facility in Honduras affected at least 11 major providers for about three hours, and HTTP traffic across the country fell 63%.

Cloudflare attributes neither event to an attack. By the end of this post you will know what happened in the quarter, what it means for a business with one website, and how to run a short check that shows where your own single points of failure are.

What happened in Q3 2026, in numbers

On 27 October 2026, Cloudflare published its quarterly report, What took the Internet offline in Q3 2026. Every number in this section comes from that report as I read it at the time of writing (2 November 2026). It covers July to September 2026 and is based on data from Cloudflare Radar, Cloudflare's public tool for watching Internet traffic around the world.

Radar recorded 49 disruptions in the quarter. The report groups the biggest share like this:

• 19 were government-directed shutdowns, and 18 of those were exam-related shutdowns in Iraq.
• 14 were power outages, spread across 10 countries.
• 5 were caused by natural disasters.

The report does not put the remaining 11 into one named category. It describes examples instead, such as a cable cut in Guyana and the incidents below.

The Phoenix data center

On 13 August, a cooling system failure at a data center in Phoenix caused a near-total drop in traffic from Namecheap (AS22612). An AS number, or autonomous system number, is the ID a network uses on the Internet, a bit like a company registration number for networks.

Heads up: this is Cloudflare's measurement of traffic, not a statement from Namecheap. The report does not say how long the drop lasted, so I will not guess either. And to be fair, cooling and power failures can hit any provider in any building. This is a story about concentration, not about one company.

The Honduras interconnection facility

On 10 September, a power failure at an interconnection facility in Honduras affected at least 11 major providers for about three hours, and national HTTP traffic fell 63%. An interconnection facility is a building where many networks plug into each other to swap traffic.

The interesting detail is who stayed online. Cloudflare notes that Telecomunicaciones de Guatemala (AS14754) and Celtel (AS52262) were not affected, possibly because their Honduran connectivity relies more on infrastructure outside the country. The report sums it up in one line: "concentrated traffic exchange points can become single points of failure."

The other events worth knowing

Cuba had four outages linked to its power grid: 6 July, 14 July (traffic down 18%), 3 August (traffic down 59%) and a three-day blackout from 18 to 20 September. Cloudflare says Cuba's disruptions "followed the erratic patterns of an unstable power grid."

In Colombia, a magnitude 7.4 earthquake in August caused a 4.5-day Internet disruption, with fiber-optic damage driving a large traffic drop at Colombia Telecomunicaciones (AS3816). In Portugal, MEO (AS3243) lost connectivity after what was reported as a "mass attack".

In Russia's Far East, on 19 September, fiber cables were damaged in Chukotka, Magadan Oblast, Kamchatka Krai and Sakhalin Oblast. Rostelecom called it "deliberate damage to backbone fiber lines" and said backup channels restored connectivity. That day fell during nationwide elections, but Cloudflare says Radar data alone cannot tell whether the two were related.

How fast things came back

Of the 49 disruptions, 14 saw traffic return to typical levels in under an hour, and 16 recovered in less than three hours. Many outages are short. The ones that hurt are the ones you did not plan for.

Why this matters: if your site is offline for two hours, you lose some visits. If your email is offline for the same two hours because it lives on the same server, you also miss orders, invoices and password resets.

What the report did not cover

The text of the report does not describe outages in the UAE, India, Pakistan or the UK. If you run a site from one of those places, this report is not a record of local events there. Please do not read it as saying those countries had no outages, or that they had some. It simply did not cover them.

What a single point of failure actually is

A single point of failure is one part of a system that, if it breaks, takes everything else down with it.

Think of a house where the front door is also the only door, the only window and the only way to get mail. If the lock jams, you cannot get in, nobody can deliver post, and you cannot even shout out a window. Most small business websites are built like that house without anyone deciding it on purpose.

For a typical one-site business, the parts are your domain registration, your DNS (the system that tells the world which server your domain points to), your web hosting, your email, and your backups. When several of them share the same physical facility, network path or control account, one failure can take them down together. Using one company is a clue to investigate, but it does not by itself prove the services share a building or failure domain.

What this means for a one-site business

From here on, these are this blog's recommendations and my own inference from the report. Cloudflare's post gives no advice to site owners. It only describes what happened.

• Avoid having everything in one facility. Your backups should live somewhere other than the server they protect.
• Keep DNS and email independent of the web host where possible. If the web server goes down, your domain can still answer and your email can still arrive.
• Monitor from outside. A check that runs on the same server cannot tell you the server is down.
• Test restores. A backup you have never restored is a hope, not a plan.

Quick tip: you do not need to do all four this week. Moving recoverable backups off the server closes one common high-impact gap.

Made-up example: Priya runs a small bakery site with online cake orders. Her domain, DNS, website and email are all on one hosting plan in one data center. The building loses cooling one afternoon. Her site is down, but worse, customers who email to ask about their order get no reply, and her order confirmations stop. If her email had been with a separate provider, she could have kept answering customers and posted a note on social media while she waited.

Before you start

This check is read-only. You will look at your setup, not change it.

• Time: it depends on how many providers and control panels you need to check.
• Risk level: the commands below are read-only, but their output can reveal infrastructure details. Keep the notes private and do not paste raw internal records into public forums. Changing DNS or email later is a separate job with its own risks.
• Access: the login for your domain registrar and your hosting control panel.
• Tools: a terminal with dig and curl installed, or a colleague who has them.
• A notepad: write down what you find, provider by provider.

A practical resilience check

Step 1: Find out who runs your DNS

Your nameservers decide who answers DNS questions for your domain. This command asks for your domain's NS records (the list of nameservers) and prints a short answer.

dig example.com NS +short

You should see two or more hostnames ending in a full stop. Write down the company those names belong to. If they belong to your web host, your DNS and website share a provider relationship. That is a dependency signal, but you still need to ask whether DNS runs on separate infrastructure and networks.

To compare, this command asks a public resolver, Cloudflare's 1.1.1.1, the same question.

dig @1.1.1.1 example.com NS +short

The two answers should match. If they do not, a recent change may still be spreading, which my post on lowering DNS TTL before a hosting move explains.

Step 2: Find out where your email lives

Your MX records tell other mail servers where to deliver your email. This command lists them.

dig example.com MX +short

Each line shows a priority number and a mail server name. If the mail server name points to your web server, the two services may share a failure domain. If it only uses your hosting company's name, ask where mail actually runs: one provider can operate separate facilities and networks.

Step 3: Find out where your website lives

This command prints the IP address your domain points to.

dig example.com A +short

You should see an address such as 192.0.2.10. Compare it with the server IP shown in your hosting control panel. Now you know which provider, and roughly which server, your site depends on.

Step 4: Find out where your backups live

Open your hosting control panel and check where backups are stored. If the only copy sits on the same server, that copy cannot help when the server or account is unavailable. A backup with the same provider may still be separate, so verify its account, storage region or facility, retention and whether you can retrieve it during a hosting outage. My guide on backing up a cPanel site to an offsite copy and testing the restore walks through fixing it step by step.

Step 5: Decide what to separate first

Look at your notes. If one company appears next to DNS, email, website and backups, pick the one change that protects you most. For most businesses that is backups first, then email.

If you decide to move a service, plan it first. My website migration plan for moving to a new host covers the order of steps so nothing breaks in between.

How to check it worked

After any change, rerun the commands from the steps above and confirm the answers show the provider you expect.

This command performs a normal GET request, discards the response body and prints the HTTP status. It avoids false alarms from sites that reject the separate HEAD method used by curl -I.

curl -sS -o /dev/null -w 'HTTP %{http_code}\n' https://example.com/

You should see a code such as 200 or a redirect such as 301. If the command shows a connection error, the server is not answering from that network. A 4xx or 5xx status still proves that an HTTP endpoint answered, but it also needs investigation.

To see whether a problem is bigger than your site, look at Cloudflare Radar's Outage Center. According to Cloudflare's Radar documentation, it provides data on outages around the world, including location, cause, scope and duration. If your country or your host's network shows up there, a wider event may be contributing. That is context, not proof about your site, so test from a second network and check your provider's status channel too. My post on a website that is down for some users shows how to read it during a live incident.

Quick tip: once a month, open your site on a phone using mobile data instead of your office Wi-Fi. It is a different network, which is the whole point of checking from outside.

What if...

What if the dig command is not found?

The symptom is a message like command not found. The tool is not installed on that machine. On Windows you can ask a colleague with macOS or Linux, or use the nslookup tool, which is a different program with different syntax, so look up its own documentation before relying on it.

What if the NS answer is empty?

If dig example.com NS +short prints nothing, check that you typed the bare domain without www or https://. If it is still empty, ask your registrar to confirm the nameservers set for the domain.

What if my host also runs my DNS and I am happy with that?

That is a fair choice. Many good providers run DNS well. The point is to know about the dependency, and to make sure your backups and, ideally, your email do not share it.

What if moving my email feels too risky?

Then do not move it yet. Start with offsite backups, which carry far less risk. Email moves need careful planning of MX records and mailbox copies, and they deserve their own afternoon.

What if my site went down and I do not know why?

This post is about planning, not live diagnosis. Check Cloudflare Radar's Outage Center, run the GET-based curl check from a second network, and contact your host with the exact time and what you saw.

What if my provider had an outage in this report?

One incident does not make a provider bad. Ask them what they changed afterwards, check your own backups, and decide calmly. A move made in a panic is often riskier than the outage.

The one message worth forwarding

Send this to whoever looks after your website:

"Hi, I read Cloudflare's Q3 2026 Internet disruption report. Many outages came from one physical failure in one place. Could you tell me which company runs our DNS, our email, our website and our backups? If they are all with one provider or one data center, can we at least move our backups offsite this month, and then talk about email? Thanks."

Outages will keep happening, so the goal is that one failed building can only take down one part of your business.