Cloud outage preparedness stopped being a nice-to-have this month. In a span of roughly 48 hours, Microsoft Azure lost a big chunk of its West US footprint and Amazon Web Services dropped connectivity between its us-west-2 region in Oregon and the Seattle metro. The AWS event alone rippled outward and knocked DoorDash, Reddit, Hulu, Apple Pay, Snapchat, Fortnite, and the PlayStation Network offline for millions of users, according to incident trackers. Neither outage was caused by anything exotic. Both came down to network routing and control-plane behavior, the boring plumbing that quietly holds the internet together until it does not. If you run an on-call rotation, the lesson is uncomfortable but clear: the next major outage is not a question of if, it is a question of when, and your response process is the only part of this you actually control.
This post breaks down what happened in late July 2026, why respected analysts now treat multi-day hyperscaler outages as a baseline expectation rather than a tail risk, and what practical changes on-call and incident-management teams should make before the next one lands. The goal is not to scare anyone about the cloud. It is to help you build cloud outage preparedness into the muscle memory of your team so that when a provider stumbles, your response is fast, calm, and coordinated instead of a scramble across five tools and three group chats.
The two incidents that bracketed the last week of July are worth understanding in detail, because the mechanics tell you a lot about where modern reliability actually breaks.
On July 23, 2026, Microsoft Azure customers in the West US region hit intermittent connectivity failures for a little under five hours. The reported cause was a defect in how a maintenance request was translated into device configuration. The change pulled routes off a wider set of network devices than intended, and that effectively cut the datacenter off from the wide-area network. Ingress and egress both suffered. Nothing was on fire, no cable was cut, and no attacker was involved. A routine operation touched more of the network than anyone expected, and the blast radius grew accordingly. This is the single most common shape of a serious cloud incident: a control-plane action that behaves correctly in a narrow test but interacts badly with production scale.
The very next day, July 24, 2026, AWS lost connectivity between us-west-2 (Oregon) and the Seattle metro. Networking hardware on the path between the region and Seattle failed at 10:55 UTC. Engineers were engaged by 11:01 UTC, connectivity began returning at 11:15 UTC, and routing was fully restored by 11:59 UTC. For most customers the hard impact window was around 20 minutes. For a subset using AWS Direct Connect through specific Seattle interconnect facilities, it stretched to roughly an hour and seventeen minutes. On paper that is a short outage. In practice, that short window took down consumer services used by hundreds of millions of people, because so much of the modern web funnels through a handful of regions. Incident trackers recorded nine confirmed cascade incidents across seven providers, plus three more possible cascades. You can read a detailed writeup of the AWS timeline on IncidentHub.
Put the two together and a pattern jumps out. Different providers, different root causes, one shared theme: the failure was in the network path and the control plane, not in the compute or storage that most teams design their redundancy around. You can run three availability zones and still be dark if the region cannot talk to the rest of the internet.
It would be easy to write these off as bad luck clustered in a single week. The industry data says otherwise. Analysts and reliability trackers have spent 2026 arguing that outages have moved from rare weather events to a predictable operating condition.
Research firm Forrester has predicted at least two major multi-day hyperscaler outages in 2026, tied to a specific structural cause: AWS, Azure, and Google Cloud are pouring investment into GPU-dense, AI-first datacenters while older x86 and ARM infrastructure ages and grows more complex to operate. When capital and attention shift toward the new shiny fleet, the legacy fleet that still runs most production workloads gets thinner margins for error. TechTarget's coverage frames it bluntly: an outage is no longer a risk, it is a certainty, and that is not expected to change this year.
Concentration risk compounds the problem. As more of the economy depends on a small group of hyperscalers, each incident affects a larger surface area. A single control-plane failure can cascade across regions within one provider at the same time, which means even a carefully designed multi-region deployment offers no protection when the control plane itself is the thing that breaks. Edge, CDN, and DNS layers make it worse, because a wobble in one of those shared services ripples out to thousands of downstream sites and applications in seconds.
The AWS us-west-2 event was, by several accounts, the third notable AWS reliability incident in roughly three months, following a datacenter thermal event earlier in the spring and a network disruption in early summer. When the same region has three bad days in a quarter, "rare" is not the right mental model anymore. The teams that adapt fastest are the ones who stop treating outages as freak occurrences and start treating provider failure as a normal, expected input to their own reliability planning.
There is also a sobering economic angle. The 2025 incidents made clear that as systems grow more interdependent, recovery gets slower and more painful, with cascading effects sometimes taking days to fully unwind. A twenty-minute network fault is rarely twenty minutes of customer impact once queues back up, caches go cold, retries stampede, and dependent services time out in sequence. That gap between provider recovery and full service recovery is exactly where good incident response either shines or fails. It is also the part of the timeline that belongs entirely to you, which is both the bad news and the opportunity.
You cannot patch someone else's network hardware or fix a hyperscaler's route propagation. What you can do is make sure that when their bad day arrives, your team detects it early, communicates clearly, and recovers predictably. Cloud outage preparedness is mostly about process, not infrastructure spend. Here is where to focus.
The most expensive minutes of any provider outage are the ones your engineers spend debugging their own code before realizing the problem is upstream. Build a fast path to answer the provider question. That means health dashboards that pull from provider status pages and third-party trackers, synthetic checks that exercise the dependency directly, and an alert design that surfaces "elevated error rate across many unrelated services" as a distinct signal from "one service is misbehaving." When a wide swath of your telemetry degrades at once and none of your recent deploys line up with it, that is a strong tell that the fault is external. Getting to that conclusion in three minutes instead of thirty changes the entire shape of the incident.
Generic incident runbooks assume you can fix the thing. Provider outages are different because the fix is often "wait and communicate well." Write a dedicated runbook for the case where a core dependency is down and you cannot repair it. It should spell out who declares the incident, how you confirm the provider is the cause, what you tell customers and when, which features you degrade gracefully versus fully disable, and how you decide whether to fail over to another region or provider. Failover is not free. It carries its own risk, and in a short 20-minute outage the failover itself can cause more damage than the outage. Deciding that calculus live, under pressure, is how teams make things worse. Decide it in advance.
During a cascading outage, the coordination overhead is often larger than the technical work. Who is paged, who is the incident commander, which channel is the source of truth, and how do stakeholders get updates without interrupting responders. If any of that depends on someone remembering a process under stress, it will break exactly when you need it most. This is where a Slack-native on-call and incident-management tool earns its place. When the alert, the escalation, the incident channel, the responder roster, and the status updates all live in the same place your team already works, you cut the number of context switches at the worst possible moment.
A runbook nobody has exercised is a document, not a capability. Run game days that simulate a hyperscaler region going dark. Time how long it takes to declare, to identify the provider as the cause, to post the first customer-facing update, and to reach a stable degraded state. Track those numbers across drills and drive them down. The teams that handled the July incidents gracefully were not lucky. They had rehearsed the exact motion.
If you want a concrete starting point, use the list below as a readiness audit. Most teams will find two or three gaps they can close this quarter without any new infrastructure.
The through-line across every one of the July incidents is that the technical outage was short, but the human coordination around it determined how badly customers were affected. A provider fixes their routing in an hour. Your team's ability to detect, declare, communicate, and recover is what fills that hour with either calm coordination or chaos. That is precisely the seam a tool like Pagerly is built for.
Because Pagerly lives inside Slack, the place most engineering teams already spend their day, it collapses the distance between an alert firing and a team responding. On-call schedules and escalation policies are managed where people work, so paging the right person does not require jumping into a separate console. When an incident is declared, the responder roster, the dedicated incident channel, and the running timeline all sit together, which matters enormously when a cascading outage is generating noise across a dozen services at once. Stakeholders can follow along without pinging responders, and the record you need for the postmortem is captured automatically as the incident unfolds.
None of this prevents the AWS or Azure control plane from having a bad day. Nothing you buy will. What it does is remove the coordination tax that turns a 20-minute provider outage into a two-hour internal fire drill. When detection, escalation, and communication are fast and native to your team's workflow, the length of the outage is set by the provider, not multiplied by your own friction. For a deeper look at how one of these events played out, see Pagerly's writeup on what the July 24 AWS outage taught on-call teams.
Two hyperscaler outages in two days, a third strike on the same AWS region inside a quarter, and a credible analyst forecast of more multi-day incidents to come. The message is not that the cloud is broken. Hyperscalers still deliver reliability that almost no organization could match on its own. The message is that provider outages are now a normal operating condition, and the teams that treat them that way will outperform the teams still hoping to get lucky.
You cannot control the network hardware between Oregon and Seattle, or how Azure translates a maintenance request. You can control whether your team knows within minutes that the fault is upstream, whether your runbook tells you exactly what to do, whether your escalation is instant, and whether your customer communication goes out in five minutes instead of fifty. That is what cloud outage preparedness actually means. Invest in the response, rehearse it until it is boring, and keep it close to where your team already works. Treat every provider outage as a free rehearsal for the next one, capture the lessons in a blameless postmortem, and feed them straight back into your runbook. The next major outage will come. The only open question is how ready you are when it does.
