The website stops loading, but the server console shows a healthy VM. Before restarting the machine, consider how a visitor reaches it. DNS must resolve the name, the network must carry packets to the destination and any edge service must be able to handle the request. Only then can the application do its work.

A failure anywhere along that path can look like a cloud outage. The recovery action depends on where it occurred.

DNS resolution and routing

Authoritative DNS servers provide the records for a domain. Cloudflare's DNS concepts documentation explains the difference between authoritative servers and recursive resolvers. A recursive resolver can serve a cached record even when it cannot fetch a fresh one. As those cached records expire, the impact of an authoritative DNS failure can grow.

A correct DNS answer does not prove that the destination is reachable. BGP, defined in RFC 4271, exchanges network reachability information between autonomous systems. A BGP route describes how a network prefix can be reached under routing policy; it does not report the health of individual applications within that prefix.

If a prefix becomes unreachable, a healthy server can disappear from parts of the internet. If the route remains reachable, the application could still be unavailable. A successful ping is not proof that HTTPS or a database connection works either.

How a backbone failure became a DNS outage

Meta's postmortem of 4 October 2021 describes a maintenance operation that disconnected its data centers from its backbone. DNS servers lost connectivity to the facilities and withdrew their BGP advertisements. As a result, the authoritative DNS infrastructure became unreachable even though the servers were still operational.

The public symptom was failed DNS resolution. The initiating event involved the backbone, followed by routing changes that affected DNS. Internal recovery tools also depended on the infrastructure that had failed.

This is a useful example of why an incident report should distinguish the first observable symptom from the actual failure. Replacing DNS records would not have repaired that backbone.

What an edge provider can and cannot deliver

A CDN can serve cached content without contacting the origin for every request. A public image may remain available during an origin failure. A login request or an uncached API call may still depend on the origin, authentication service or database.

Cloudflare's June 12, 2025 incident report documents a failure affecting the storage infrastructure used by Workers KV and several services relying on it. Cloudflare said its core DNS, cache, proxy and WAF services were not directly affected. The scope was product-specific rather than a complete failure of the entire network.

That example matters to customers choosing multiple providers. Two services bearing different company names can still depend on common upstream infrastructure. Conversely, different products offered by the same company may continue operating independently through an incident.

Symptoms that narrow the search

Consider a site behind a reverse proxy. During an incident, compare several observations before assigning a cause:

  • A DNS lookup returning no usable answer points toward resolution or DNS reachability, but routing can be an underlying cause.
  • A correct address with connection failures from one network but not another suggests a path-specific problem. Filtering, routing and service behavior all deserve investigation.
  • A response from the CDN containing an origin error shows that the edge answered; it does not prove that the origin application is down. Connectivity, TLS and origin access rules may also be involved.
  • Cached static files loading while account operations fail suggests examining the uncached request path and its dependencies.
  • An application returning errors directly may have a database, authentication or software problem even when DNS and network reachability are normal.

None of these observations is sufficient by itself. Compare independent monitoring locations and account for caches. Direct origin checks, where authorized, must use the correct hostname, TLS server name and expected access policy; bypassing the CDN can otherwise create an unrelated failure.

Recovery depends on the failed layer

A secondary application server cannot repair an unavailable authoritative DNS service. A second edge provider cannot create a missing database replica. Adding another network path does not fix a bad application release deployed to every origin.

The sensible resilience plan follows the complete customer request, identifying where independent capacity or state is required. See multi-cloud resilience and shared dependencies for why provider diversity does not necessarily remove those single points of failure.