UII UPDATE 514 | JULY 2026
An outage of a cloud data center does not necessarily cause an outage of a cloud application. Applications designed to operate across availability zones and cloud regions can continue to perform during outages. Indeed, cloud providers make it clear that customers should design their applications to account for occasional infrastructure failures (see Build resilient apps: do not rely solely on cloud infrastructure).
In 2025, Microsoft Azure, Google Cloud and Amazon Web Services (AWS) all continued to experience occasional zone and region outages. For customers who had not architected dual-zone or dual-region resiliency, applications hosted in affected locations likely experienced downtime. But some outages affected even those organizations that had diligently planned for failure. Google Cloud and Microsoft Azure both suffered from widespread, multi-region outages in 2025. In these cases, even if failover to another region had been planned, application downtime likely occurred.
In 2024, Uptime Intelligence collected availability status updates from AWS, Google Cloud and Microsoft Azure to measure historical availability rates (see Outage data shows cloud apps must be designed for failure). The research determined whether incidents reported in these historical status updates would have affected applications architected using virtual machines deployed in:
In this report, the exercise is repeated using data from 2025. Analysis shows that while average availability of basic cloud services improved, customers in availability zones and cloud regions that were the worst-affected by outages were at risk of considerably more downtime. Cloud outages are rare, but when they happen, consequences for those that are unprepared are becoming worse.
An application's availability depends on the cloud services it uses and its architecture. An outage of a particular service will not affect an application if it does not use that service.
To measure availability, we use a simple application architecture that consists of virtual machines, load balancing and DNS. We assume that incidents affecting services required to operate or recover the application would materially impair its availability. This includes issues that affect latency, error rates or control planes, even if the provider does not report a full outage. We measure duration from the first time the incident is reported to its full resolution.
This approach provides a means of measuring relative performance of resiliency architectures across time periods. However, it does not provide an absolute measure of availability.
In 2025, multiple major outages were likely to have impacted applications hosted in the affected zones and regions:
There were also significant outages that would not affect the example architecture but are noteworthy for their wide-reaching impact. The largest was the Azure Front Door global outage in October 2025 (see What the Azure outage revealed about internet fragility).
Figure 1 shows the availability of the worst-performing regions in 2025, along with the average, across the different application resiliency architectures. Most regions would have provided 100% application availability over the period.
Figure 1 Average and worst-case availability by architecture in 2024 and 2025

On average, applications hosted in single and dual zones experienced less than half the annual downtime of 2024. Applications hosted across regions experienced around three-quarters less downtime in 2025 than in the previous year.
However, average availability paints an optimistic picture. Most availability zones experience little or no downtime in a typical year, making single-zone deployment appear reasonable. But major outages are usually concentrated in a small number of locations. Organizations with applications that happen to be deployed in one of these zones can experience dramatically worse availability.
An application hosted entirely within a zone that suffered a substantial outage (such as Azure's East US 2 failure in January 2025) would have experienced more than 46.6 hours of downtime — nearly twice as long as in 2024.
An application hosted in two zones also saw more downtime when the worst case is examined. An application downtime of 21.5 hours would have occurred in 2025, double that of 2024. Whole-region failures, such as AWS's October 2025 failure in us-east-1, affect several availability zones and can have a significant negative impact even on the more resilient applications.
Even with major multi-region outages, as in the case of Google Cloud's June 2025 incident, applications distributed across regions (engineered to a very high level of resiliency) generally performed well. In the worst case, application downtime was 6 hours per annum, slightly above the previous year's 5.1 hours.
Unfortunately, there are cost and carbon implications to multi-region and multi-zone availability architectures. A single zone, statistically, provides a good level of availability. But if that zone fails, the impact of an outage can be long-lasting and costly, with little ability to recover beyond waiting on the cloud provider to restore service. Compensation from cloud providers is not designed to offset losses from downtime (see Cloud SLAs punish, not compensate).
As with all workload placement decisions, organizations need to balance availability, cost and carbon against other qualitative requirements to ensure they protect their business without paying more than necessary (see Cloud: when high availability hurts sustainability).
Table 1 Annual availability by architecture and year (with downtime in parentheses)

Generally, cloud providers continue to deliver good availability across zones and regions. However, when a zone does suffer an outage, the downtime can be significant. Which zones will suffer serious outages is largely a matter of chance. The data show that duplication reduces the impact of a cloud outage. However, there are cost, carbon and technical implications for building resiliency. Organizations need to balance application availability against these considerations.