What an outage is
An outage is a period when a service is unavailable or badly degraded. Sometimes everything is down. Often only some features, some regions or some users are affected, which is why people on the same app can have very different experiences during the same incident.
Large cloud providers are designed to keep running despite failures, and they usually succeed. But the systems are enormous and complex, and when they fail, many other services can fail with them, making cloud outages newsworthy.
Common causes
Public incident write-ups from providers over the years tend to fall into a few broad categories. The exact mix varies, and no list is complete.
Configuration and software changes. Probably the most commonly cited cause is a change made by the provider’s own engineers or automation: a faulty update, a wrong setting, or a mistake in a network rule. Because changes are rolled out to many machines through automation, a mistake can spread quickly. Providers usually release changes gradually to limit this, but not every problem shows up in testing.
Hardware failures. Drives, memory, power supplies and network cards all fail eventually. Individual failures are normal and handled by redundancy. Trouble arises when failures cluster, or when a backup path does not work as expected.
Power and cooling problems. A data center depends on electricity and cooling. Backup batteries and generators are meant to bridge utility power cuts, but they can themselves fail. A cooling fault can force equipment to shut down to avoid overheating. The role of cooling is described further under data center energy.
Network faults. A router misconfiguration, a damaged fiber cable, or a problem with how networks advertise routes to one another can make a service unreachable even when the servers are fine. Related name-lookup failures in the domain name system can also make working sites appear to vanish, because browsers cannot find their addresses.
Overload. A sudden surge in traffic, or a smaller problem that causes many clients to retry at once, can overwhelm a system. Retries are well meant but can pile extra load on a service that is already struggling.
Software bugs and capacity limits. Some bugs only appear at scale or under rare conditions. A hidden limit, such as a maximum number of connections or a full storage volume, can also cause sudden failure.
Security incidents. Malicious activity, such as a flood of traffic meant to overwhelm a service or ransomware attacks on a customer’s systems, can also cause downtime, although most large cloud incidents described publicly involve internal faults rather than attacks.
Human error and process gaps. Many post-incident reviews describe a chain of small issues rather than a single villain: an unclear procedure, a missing alert, a rushed change. Good reviews focus on fixing the process.
Why one fault can spread widely
Several features of modern systems explain why a local fault becomes a broad one.
Shared foundations. Thousands of customers rely on the same underlying services, such as identity checks, storage, databases and networking. If a foundational service falters, everything built on it feels it. The layered design is outlined in cloud infrastructure.
Hidden dependencies. A website may run in one place but depend on a separate service for logins, another for payments, another for images, and another for analytics. A company can believe it is independent of a given provider and still be affected through a vendor it relies on. Often even the engineers involved did not know about the dependency until it failed.
Cascading failures. When one component slows down, the components calling it wait longer, use more resources, and may fail in turn. That can ripple outward, so a small slowdown turns into a large failure.
Concentration. A large share of the internet’s traffic runs on a small number of providers and on specific regions within them. If a popular region has a problem, a large number of apps are affected at the same moment. Many customers choose the default or cheapest region, which increases that concentration.
Recovery takes time. Even after the root cause is fixed, services often restart gradually. Caches are empty, queues of backed-up work must be processed, and engineers restore capacity carefully so that the recovery itself does not cause a second overload.
What gets affected
During a major incident, people have reported effects such as:
- websites and apps failing to load or log in
- smart home gadgets, including many IoT devices, becoming unresponsive because they rely on a cloud service
- payment and ordering systems pausing, which affects online shopping
- internal business tools, email or video meetings being unavailable
- the provider’s own status page or support tools being slow, because they may depend on the same infrastructure
Impact depends on how a service is built. Something that can work offline, or that stores a local copy, may continue in a limited way, while something that checks a remote server on every action will stop.
How providers and customers reduce the risk
Providers use redundancy: multiple data centers per region, separate power feeds, gradual rollouts, automated health checks, and practiced incident response. Customers can add their own protection, although each step costs money and effort:
- spreading a workload across more than one availability zone, and sometimes more than one region
- designing apps to degrade gracefully, for example showing saved information if a live feed is unavailable
- using timeouts and sensible retry limits so that failures do not snowball
- keeping tested data backups outside the main system
- understanding which third-party services the application relies on
- rehearsing what the team will do during an outage
For some organizations, a mixed arrangement such as hybrid cloud adds options, but it also adds complexity of its own and does not remove the possibility of failure.
A realistic expectation
No system is perfectly reliable. Providers often publish availability targets, but a high percentage still allows some downtime over a year, and the target is a goal, not a guarantee. The practical question for any organization is how much downtime it can tolerate, and how much it is willing to spend to reduce it.