In a single week of July 2026, cloud outages knocked large parts of the internet offline more than once. On July 23, an automation bug during routine network maintenance removed IP routes from a West US Azure datacenter and disrupted Microsoft 365, Teams, and dozens of Azure services for nearly five hours. The next morning, July 24, AWS lost network connectivity between its us-west-2 region in Oregon and the Seattle Metro, and DoorDash, Reddit, Hulu, Apple Pay, Snapchat, and the PlayStation Network went dark for millions of users. Add a CloudFront incident on July 16, a Meta disruption on July 22, and a T-Mobile mobile network outage on July 27, and you have a stretch that reads like a stress test for the entire ecosystem.
If you run on-call, the lesson is not that any one provider is uniquely fragile. The lesson is that these cloud outages share a pattern worth studying, because the same pattern will eventually reach your own systems. This post breaks down what actually happened, why routine changes and network routing keep causing large outages, and what practical steps on-call and incident response teams can take so that the next provider failure is a controlled event rather than a scramble.
It is tempting to treat each of these incidents as an isolated headline. Looked at together, they tell a more useful story. The two biggest events of the week, Azure on July 23 and AWS on July 24, were not caused by exotic hardware failures or external attacks. They were caused by the plumbing that carries network routes, and in Azure's case, by automation acting on that plumbing.
Microsoft was unusually direct about the cause. A bug in Azure's maintenance request conversion system incorrectly marked additional network devices as part of a routine maintenance event. The system then removed IP routes from more devices than intended, cutting connectivity between a West US datacenter and the wide area network. Customer impact ran from 14:44 UTC to 19:41 UTC, roughly four hours and 57 minutes, and the list of affected services was long: App Service, Application Gateway, Azure Kubernetes Service, Cosmos DB, ExpressRoute, Microsoft Graph, Sentinel, Virtual WAN, and many more. The network rollback completed at 18:26 UTC, and full recovery was declared at 19:41 UTC. You can read a detailed timeline in this Azure West US postmortem writeup and Microsoft's own explanation covered by Network World.
The important detail is not the specific subsystem. It is that a maintenance workflow, the kind of change teams run constantly, expanded its blast radius beyond what anyone intended. Automation did exactly what it was told to do, and what it was told to do was wrong.
The next day, AWS lost connectivity between us-west-2 in Oregon and the Seattle Metro. The company attributed the fault to the networking hardware that carries routing between the region and Seattle. The disruption began around 6:40 a.m. ET. Most customers saw impact for roughly 20 minutes, while a subset relying on AWS Direct Connect experienced closer to one hour and 17 minutes of trouble. Because so many consumer brands run in that region, the effects rippled outward fast, taking down Apple Pay, Reddit, Hulu, DoorDash, Snapchat, Fortnite, and the PlayStation Network. A breakdown of the routing failure and the long recovery tail is documented in this us-west-2 outage analysis, and coverage from Tech Times noted this was the third notable AWS reliability incident in about three months, following a data center thermal event in May and a network disruption in June.
The supporting cast reinforced the theme. Earlier in the month, AWS CloudFront customers using VPC Origins saw a multi hour disruption tied to an internal connection management limit that prevented routing configurations from loading. Meta had a global disruption on July 22. T-Mobile users in the United States logged more than 220,000 reports on Downdetector on July 27. Different companies, different stacks, but a recurring theme of network reachability and configuration change sitting at the center of the failure. For a running log of the week, the 2026 network outage report is a useful reference.
When people imagine an outage, they often picture a server catching fire or a disk failing. Those events happen, but they are not what takes down half the internet for an afternoon. The dominant cause of large scale disruption is change: a deployment, a configuration edit, a maintenance workflow, or an automated process acting on the network. The July 2026 cloud outages are a clean illustration.
This is not a new observation. A widely cited Gartner research note projected that around 80 percent of outages impacting mission critical services would stem from people and process issues, and that more than half of those would trace back to change, configuration, and release integration specifically. Different studies classify incidents differently, but the direction is consistent across the industry: the changes we make to keep systems healthy are also the leading way we break them. Practitioners have written at length about this, from analyses of configuration change outage trends to broader arguments that most production outages are self inflicted.
The most dangerous sentence in an incident channel is "nothing changed." In the Azure case, something absolutely changed: a maintenance event ran, and an automation bug widened its scope. The teams downstream who lost Teams and Cosmos DB access did not change anything themselves, yet a change upstream still reached them. This is the uncomfortable truth of running on shared infrastructure. Your blast radius includes every change your providers make, whether you approved it or not.
For on-call engineers, this reframes the first few minutes of an incident. Instead of asking only "what did we deploy," the better opening questions are "what changed anywhere in our dependency chain" and "is our provider reporting anything." A surprising number of severity one incidents are resolved not by fixing your own code but by correctly identifying that the problem lives upstream and switching into a communication and mitigation posture rather than a debugging one.
Both marquee outages were regional. Azure's problem was a West US datacenter. AWS's problem was Oregon losing its path to Seattle. Yet the consumer impact was global, because so many services concentrate their footprint in one region for cost and simplicity. Concentration is efficient right up until the region has a bad day, at which point efficiency becomes correlated failure. Multi region and multi provider architectures reduce this, but they are expensive and complex, and most teams cannot flip that switch mid incident. What every team can do is understand its own concentration risk before the incident, so that when a region degrades, the response is informed rather than surprised.
The uncomfortable headline for on-call teams is simple: you will be paged for outages you did not cause and cannot directly fix. That does not make your response any less important. During a provider outage, your job shifts from remediation to coordination, communication, and mitigation. Doing that well is the difference between a calm hour and a chaotic one.
In several of these events, users noticed before status pages updated. Provider status dashboards are often conservative and lag real customer pain. Your own monitoring, synthetic checks, and error rate alerts should be the first signal, not a tweet from an angry user. If your alerting only fires when your own service throws errors, you may miss the early minutes of a dependency failure that is degrading experience without tripping your internal thresholds.
When Apple Pay and DoorDash went down at 6:40 a.m. Eastern, the teams that recovered fastest were the ones where a specific human owned the incident within a minute or two. Ambiguity about who is running the incident is the most common way response time balloons. A clear on-call rotation, an unambiguous escalation path, and a single incident commander per event are the difference between coordinated action and five engineers independently guessing.
During a widely publicized provider outage, your stakeholders already know something is wrong. Silence reads as incompetence. A short, honest, regularly updated status message, internally to leadership and support, and externally to customers, buys enormous goodwill. The teams that struggle are the ones improvising communication while also trying to mitigate. The teams that do well have a template and a channel ready before the incident starts.
Here is a concrete playbook you can adapt. It assumes the failure is upstream, at a cloud or network provider, which is exactly the scenario the July 2026 cloud outages represent.
The opening moves matter most. First, confirm scope. Is this your code, or is it upstream? Check provider status and your dependency dashboards immediately. Second, declare and assign. Name the incident commander and open a single coordination channel so everyone works from one source of truth instead of scattered threads. Third, communicate early and often, even when the update is "we are investigating and will report again in 15 minutes." Fourth, mitigate what you can: failover to a healthy region if you have one, degrade gracefully by disabling non essential features, and protect the core experience. Fifth, log a timeline as you go, because reconstructing it afterward from memory is painful and inaccurate.
When service is restored, resist the urge to move on. A blameless postmortem, focused on systems and process rather than individuals, is where the real value lives. Capture the timeline, the detection gap, the decisions that helped, and the ones that did not. Turn findings into concrete action items with owners and dates. The Azure and AWS teams will publish their own analyses; your job is to write the internal version that answers "if our provider does this again, are we faster next time." A good postmortem culture is one of the strongest predictors of improving reliability over time, a theme echoed across modern SRE reliability practices.
Most of the playbook above comes down to speed and coordination, and coordination happens where your team already talks. For a large share of engineering teams, that place is Slack. When an outage hits, the last thing you want is for responders to context switch into a separate tool, hunt for who is on call, and manually assemble a war room while the clock runs.
This is the gap a Slack-native on-call and incident management tool like Pagerly is built to close. Because it lives inside Slack, it puts the essentials where responders already are: on-call schedules and rotations that anyone can check with a quick command, escalations that page the right person automatically when the first responder does not acknowledge, and one-click incident channels that spin up a dedicated space with the right people pulled in. When a provider outage lands at 6:40 a.m., the difference between a coordinated response and a scramble is often just how quickly the right human is looking at the problem in a shared space. Keeping alerting, ownership, and communication in the same tool your team lives in removes several of the small frictions that quietly stretch a 20 minute incident into an hour.
None of this prevents a cloud region from failing. Nothing you buy or build will. What it does is compress the human part of the response, the detection, ownership, and communication that you actually control, so that when the infrastructure has a bad day, your team does not.
The cluster of cloud outages in late July 2026 is a useful teacher precisely because none of the causes were exotic. They were changes, maintenance, and network routing, the ordinary machinery of running large systems. The practical lessons for on-call and incident response teams are straightforward:
Cloud outages are now a permanent feature of the landscape, not an anomaly. The providers will keep improving, and they will keep having bad days, because complex systems fail in complex ways. The teams that come through those days well are not the ones with perfect infrastructure. They are the ones who decided in advance how they would respond, put ownership and communication where their people already work, and treated every incident as a chance to be faster the next time. Build that muscle now, while the internet is calm, so the next busy week in the cloud is one your on-call team handles rather than fears.
