Why websites go down

Ask most people why a website goes down and you will hear about servers crashing, hard drives failing, or somebody hacking in. At the scale of the services people actually search about - The ones with a billion users and a dozen data centres - Almost none of that is true.

Large services are built to survive hardware failure. Machines die constantly and nobody notices, because that is the one failure mode everything has been designed around for twenty years. What takes a global service offline is nearly always something else: A change that a human made deliberately, that did exactly what it was told, in a place where nobody had modelled the consequences.

Configuration changes

This is the single largest category, and it is not close. A configuration change is more dangerous than a code deploy for a structural reason: Code usually rolls out gradually, region by region, with automated rollback if error rates climb. Configuration frequently propagates everywhere in seconds, because that is the point of it.

The pattern repeats across the industry. A routing rule, a firewall policy, a rate limit, a feature flag or a DNS record is pushed globally, it contains a mistake, and every point of presence applies the mistake simultaneously and correctly. There is no canary because configuration was never treated as code. The recovery is often complicated by the fact that the broken configuration has also broken the mechanism used to push a fix.

BGP and routing

The internet's routing system, BGP, works by mutual announcement: Networks tell each other which address ranges they can reach. If a network stops announcing its ranges - Deliberately or by mistake - Those addresses simply cease to exist from everyone else's perspective. Not slow. Not erroring. Gone.

This produces the most complete outages there are, because a BGP withdrawal takes the nameservers with it. Once the authoritative nameservers for a domain are unreachable, nothing about that domain resolves anywhere on Earth. The October 2021 Meta outage is the canonical example, and it illustrated the second-order horror of the category: The company's own internal tools and physical access systems depended on the same network, so the engineers who could fix it could not get to the machines.

Dependency cascades

Every service depends on other services, and most organisations do not have an accurate map of their own dependency graph. The ones that surface during an outage are almost always the ones nobody drew.

Authentication is the worst offender, because it sits under everything. If token issuance fails, no individual product is broken but none of them can be used - Which is exactly what a large Microsoft 365 incident looks like from a user's desk. Internal DNS is a close second: A name resolution failure inside a cloud provider looks, to every service running there, like every other service has disappeared at once.

This is also why one provider's incident becomes a hundred companies' incident. When a major AWS region has trouble, the visible symptom is smart doorbells, airline check-in, project trackers and streaming apps all failing in the same ten minutes. They are not related to each other; they are related to the thing underneath them.

Capacity and load

Traffic spikes cause fewer outages than people assume, because autoscaling is mature and CDNs absorb most of it. What still breaks is the part that cannot be scaled quickly: A relational database, a queue with a bounded depth, a third-party API with a fixed rate limit.

The characteristic failure here is not a crash but a spiral. Requests slow down, clients time out and retry, the retries add load, everything slows down further, and the system saturates itself. This is why an overloaded service often cannot recover on its own even after the original traffic has gone, and why operators sometimes have to shed load deliberately - The 503 responses you see during a big launch are frequently a controlled choice rather than a failure.

Expired certificates

Still, in 2026, a routine cause of complete outage. A TLS certificate has an expiry date, browsers refuse the connection the moment it passes, and the failure is total and instant - The service is running perfectly and nobody can reach it.

It persists because certificate renewal is often the responsibility of no one in particular, and because internal certificates on services that never face the public are the easiest to forget. The outage is usually short, because the cause is unmistakable, but it can be surprisingly hard to fix if the certificate that expired was the one securing the deployment pipeline.

Deploys

Deploys cause fewer outages than they used to, and the ones they cause are usually shorter, because rolling deployment and automatic rollback are now standard. The deploys that do take a service down tend to involve something that cannot be rolled back: A database migration that has already altered the schema, a data format change that older code cannot read, or a cache purge that leaves every request rebuilding from scratch against a cold database.

External and physical causes

Fibre cuts, power failures and data centre cooling problems do happen, and when they do they are regional rather than global. They are also relatively honest failures: The cause is obvious, the repair time is estimable, and the provider usually says so quickly.

Attacks are a smaller share of outages than headlines suggest. Volumetric denial of service is largely absorbed by the big mitigation networks now. What still succeeds tends to be targeted at a specific expensive endpoint - A search query, a login attempt, an API call that touches a database - Where a modest request rate does disproportionate work.

What this means when you are waiting

You cannot usually tell which of these is happening from outside. But the shape of the failure narrows it a lot, and the shape correlates with duration.

None of that changes what you can do, which is nothing. But it does change how long to wait before assuming the problem is yours, and that is worth knowing. How long outages actually last goes into the numbers.