Website single point of failure: what to do
When one company runs your domain name, your DNS and your hosting, an outage on its side takes your website offline, even while your own servers are fine. If it also handles your email, messages stop arriving at the same time. Start by finding out which provider runs what, then separate the layer that is easiest to move, usually DNS. Doubling the rest only pays off if an hour of downtime costs you a lot.
A common case goes unnoticed: a domain bought from a registrar that also kept its DNS. You can fix it without changing hosts. It is one of the first things a website dependency and resilience audit looks at.
Domain, DNS, hosting, email: what goes down together
Opening a page involves several providers, rarely chosen one at a time: DNS often comes with the domain, email with the hosting plan, and a CDN can take over your DNS too. Each one runs a layer:
- the registrar, which holds your domain registration. No visit passes through it, but it is where the domain's DNS provider is set;
- DNS, which turns the name into a server address. Every visit starts there;
- the CDN or reverse proxy in front of your server, if there is one. All traffic goes through it;
- hosting, which serves the pages;
- email, which receives mail sent to your domain.
DNS, content delivery and hosting sit on the path of every visit: if one of them stops, the site stops responding. Email does not. When it fails, the site stays up, but messages from your customers stop arriving, or arrive late.
When several of these layers sit with the same company, a single outage, or a single suspended account, stops them all at once. For an online store, every hour of downtime costs orders. For a business website, it means contact requests that never come through.
Three outages at large providers, and what each took down
Large providers spread their servers across many sites. That protects you from a failed machine, not from an error in their shared systems, and not from a disaster at the one site where everything is kept:
- On November 18, 2025, an internal configuration error at Cloudflare, not an attack, made part of its network fail for about three hours. Sites behind it returned errors to their visitors while their own servers were working.
- On October 20, 2025, a failure in the internal DNS of Amazon Web Services, in its Northern Virginia region, made many services hosted there unavailable for most of the day.
- On March 10, 2021, a fire destroyed one of OVHcloud's buildings in Strasbourg, France. Customers whose backups were kept at the same site lost their data along with their servers.
What decides the impact on your website is how many of your layers one outage takes down at once.
The last case comes down to a dependency no visitor can see: where the backups are kept. It cannot be read from outside the site. It is a question for your host.
Amazon for one site, a French operator for the other: same weak point
75%rely on one provider for at least two critical layers, including one that all traffic goes through
This percentage covers about 30 websites we audited between August 14, 2026 and September 24, 2026, the ones where this point could be checked. Many were audited because a defect showed up quickly, so the figure describes our audits, not websites in general. This finding does not rate a provider's reliability. It says how many layers would fail together if that provider stopped.
The two reports we publish show the same weakness with a US provider and with a French one. In the one on a sporting goods store, Amazon hosts the site, registers the domain name and answers its DNS queries: if Amazon stops or suspends the account, the site becomes unreachable, with no fallback.
In the one on a B2B business website, hosting and content delivery sit with US companies, but the single point of failure is elsewhere: a French operator holds both the domain registration and the DNS, which all traffic goes through. Choosing an EU provider settles the question of which law applies; it does not settle concentration.
In both cases email sits with Google, outside those layers, and each report proposes the same remedy: move DNS to a second operator. For the store, that restores a fallback without touching the hosting. For the B2B site, it removes the single point of failure while keeping the registrar.
Separate DNS first, duplicate only if downtime is expensive
These decisions are within your reach, even without a technical team. In this order, from the cheapest to the most involved:
- List your layers and the company behind each one: domain, DNS, content delivery, hosting, email, backups. Your web agency or developer can put that list together; ask them too whose name each account is in. The brand on the invoice is not always the company that runs the service.
- Find the provider that runs at least two of these layers, one of which carries all traffic: DNS, content delivery or hosting. That provider is your single point of failure.
- Separate the domain and DNS first: one of them moves to another company, and hosting stays where it is. It is often the lightest fix. Ask for it to be planned: every record for the domain, email included, must exist at the new provider before the switch, and DNS bundled with a domain does not always survive a transfer of that domain.
- Ask your host where your backups are kept: at the same site as your servers, or somewhere else.
The rest takes a project. Moving your CDN or your host means a planned migration. Doubling a layer, with a secondary DNS provider or a standby host, adds resilience, along with another subscription and another setup to keep in sync on both sides.
Decide based on what an hour of downtime costs you. For a brochure site, a known and accepted concentration can be a reasonable choice. For an online store, weigh the second subscription against the orders lost during an outage.
Concentration has upsides too: a CDN that also runs your DNS can make the site faster and better protected. Keep it if it serves you, knowing what it would take down with it.
One question: would the site still be reachable?
The audit builds the map from the first step without access to your accounts, from what the domain publishes: its name servers and zone, its mail servers, its registry record, the headers the site returns and the address it points to. It maps each technical host name back to the company that runs it, because an operator often serves DNS zones under a brand that differs from its company name, and it records which country's law that company is subject to. Then it asks one question: if this provider disappeared right now, would the site still be reachable?
- The finding is only raised if a provider runs at least two layers, one of which carries all traffic. The registrar counts as a second layer, so a domain whose DNS stayed with the company that sold it meets both conditions.
- Email appears on the map but does not count toward those two layers: when it stops, the site still responds.
- A name server the audit cannot tie to a company is flagged as unresolved and never counted as a second provider, because that would give the site the most favorable verdict with no evidence.
The report names, for each provider, the layers it runs, the ones that sit elsewhere, and the separation that would be enough, next to what that provider brings to the site. Every limit of the review is stated in the report. A point we could not verify is never presented as compliant.
The same map answers another question: which country's law each provider is subject to. The guides on what the CLOUD Act lets US authorities demand and on questions to ask an EU web host cover it.
Read next
EU web hosting: more than server location
A server in the EU is not enough: the law your host and its subcontractors answer to matters, and so do DNS and email. The questions to ask first.
Read the guide →CLOUD Act: does it apply to your website?
The CLOUD Act reaches data that US providers hold, even on servers in Europe. Which layers of your website it covers, and what to ask your providers.
Read the guide →Website data transfers outside the EU
Fonts, analytics, videos, maps: a single visit can send your visitor's IP address outside the EU. What triggers it, and what to do about it.
Read the guide →