Cloud outage response got another live fire drill on July 24, 2026, when AWS lost network connectivity between its us-west-2 region in Oregon and the Seattle metro. For most customers the pain lasted about 20 minutes, and a small set on AWS Direct Connect saw errors for roughly an hour and seventeen minutes. That is short as major cloud incidents go. What makes it worth your attention is not the duration. It is the pattern: apps like Apple Pay, Reddit, Hulu, DoorDash, and PlayStation Network went sideways, and the teams running those services often knew something was wrong before the provider status page said so. If you run on-call, that gap between "our users are hurting" and "the vendor has confirmed it" is exactly where your process either shines or falls apart.
This post breaks down what happened, why the blast radius was so uneven, and the one detail every on-call team should sit with. Then it gives you a practical cloud outage response playbook you can apply the next time a dependency you do not control decides to have a bad morning. The goal is simple: detect faster, communicate cleaner, and stop treating your provider's status page as your primary source of truth.
AWS reported that the root cause was an issue with the networking devices responsible for routing traffic between the us-west-2 region and the Seattle metro area. In plain terms, a piece of network hardware on the path connecting the region to a major interconnection hub failed. Traffic that both started and ended inside the region generally kept working. Anything that had to cross the region boundary, including some private networking and Direct Connect paths, hit timeouts and errors.
That distinction matters, and we will come back to it, because it explains why two teams running in the same AWS region could have wildly different experiences. One team saw nothing. The other watched half its user journeys fail.
Public reporting and incident trackers lined up on a fairly tight sequence of events. The networking hardware on the path between us-west-2 and the Seattle metro failed at roughly 10:55 UTC. AWS engineers were engaged by about 11:01 UTC. Connectivity started returning around 11:15 UTC, and routing was reported fully restored by 11:59 UTC. AWS posted its first public update at approximately 11:40 UTC, and said it expects to publish a formal, detailed post-incident report within two to four weeks.
Read that timeline again with an on-call hat on. The hardware failed at 10:55. The first public acknowledgment landed at 11:40. That is roughly 45 minutes during which your users were experiencing failures and the authoritative external signal you might have been waiting on did not yet exist. If your detection strategy is "watch the AWS status page," you were blind for most of the incident.
Because the failure sat on the routing path to the Seattle metro rather than inside the compute or storage layer, the impact was fundamentally about where traffic needed to travel. Intra-region traffic was largely fine. Cross-boundary traffic was not. Services that leaned on AWS Direct Connect through the EqSe2 facility at the Westin Building Exchange in Seattle took the longest hit, up to about an hour and seventeen minutes, while the broad set of affected customers recovered in around 20 minutes.
This is a useful reminder that "AWS is down" is almost never the right mental model. Cloud outages are rarely all or nothing. They are usually a specific service, a specific region, a specific availability zone, or in this case a specific network path. The teams that respond well are the ones that can quickly answer "which slice is affected, and does our critical path touch it," instead of panicking about a headline.
Here is the part that should change how you think about detection. According to incident tracking of the event, there were 9 confirmed downstream cascade incidents across 7 providers, plus a few more possible cascades. And notably, 11 of the 12 tracked incidents were opened before AWS posted its first public update at 11:40 UTC.
Sit with that. The downstream teams, the ones running the products your customers actually touch, detected and declared their own incidents before the upstream provider confirmed anything publicly. They did not wait for permission from a status page. Their own telemetry told them users were failing, and they acted on it.
That is the healthy pattern, and it is also the one that separates mature on-call operations from immature ones. The mature teams treat provider status pages as a confirmation signal and a communication aid, not as the trigger for their own response. The immature teams sit on their hands, refreshing a third party dashboard, telling themselves it cannot be their fault, while their error budget quietly burns.
The lesson is not "AWS is unreliable." Every major cloud provider has bad days, and us-west-2 alone reportedly saw multiple disruptions across a few months in 2026. The lesson is that your response cannot be gated on someone else's acknowledgment. You own the experience your users have, even when the fault lives in a dependency you do not control.
It is tempting to be cynical about provider status pages, but it helps to understand why they lag before you decide how much to rely on them.
A large provider updating a public status page is making a high stakes statement. That update goes to thousands of customers, gets quoted in the press, and can carry contractual and reputational weight. So there is an internal process: confirm the signal, scope the impact, agree on wording, and only then publish. That process is responsible, but it is also slow relative to the speed at which your users feel pain. By the time a green dot turns yellow, your customers have often been failing for many minutes.
On top of the deliberate caution, there are mechanical reasons for lag. The monitoring that feeds a status page may itself route through the affected infrastructure. Automated health checks can be coarse. And the human in the loop needs to distinguish a real regional event from noise. None of this is malicious. It just means the status page is structurally a trailing signal.
If the provider signal trails, your own signal has to lead. That means investing in a few things that pay off precisely on days like July 24:
The point is not to distrust your provider. It is to be honest about signal latency and to make sure the fastest, most reliable signal you have is the one closest to your users.
When a dependency you do not control fails, your job is not to fix their network. Your job is to protect your users, communicate honestly, and shorten your own recovery. Here is a practical sequence built around what the July 24 event rewarded.
Your first alert should come from a symptom your users feel, ideally within a minute or two of impact. If your only signal on July 24 was the AWS status page, you were roughly 45 minutes late. Tune your alerting so a meaningful jump in cross-region error rates or a drop in a key success metric pages the on-call engineer immediately, with enough context to start scoping.
Declaring an incident is cheap. A false alarm costs you a few minutes and a shrug. A late declaration costs you customer trust and a longer recovery. The downstream teams that opened incidents before AWS confirmed anything were not being dramatic. They were being correct. Once declared, immediately scope the blast radius: which region, which service, which path, and which of your user journeys actually depend on it.
Assign a communications role early and separate it from the person doing hands-on mitigation. Post a first customer-facing update quickly, even if it is only "we are aware of degraded performance affecting some users and are investigating." Then hold to a cadence, for example an update every 20 to 30 minutes, until resolution. Note that on July 24, downstream services took longer to recover than AWS itself did, so keep communicating through your own recovery tail rather than declaring victory the moment the upstream turns green.
You cannot repair a provider's routing hardware, but you are rarely as helpless as you feel. Depending on your architecture, options may include failing over to another region, shifting traffic away from the affected path, degrading gracefully by disabling nonessential features, serving cached or read-only responses, or queuing writes for later reconciliation. The teams that plan these moves in advance execute them calmly. The teams that improvise under pressure often make the incident worse, which is exactly what happened to at least one company in July 2026 that scaled up workers mid-incident and exhausted its own database connection pool.
When it is over, run a blameless postmortem even though the root cause was not yours. The interesting questions are about your response, not the provider's hardware: How long from user impact to detection? From detection to declaration? Did the right people get paged, or did the alert bounce around? Was communication clear? Would a region failover have helped, and why was or was not it available? A dependency's outage is one of the best free lessons you will get about the resilience of your own response.
Everything above lives or dies on how fast the right humans get engaged and how cleanly they coordinate once they are. This is where the tooling around on-call matters, and it is where a Slack-native approach earns its keep.
Most engineering teams already live in Slack all day. When your on-call, alerting, and incident coordination happen in the same place where the team already talks, you remove the friction that costs precious minutes at the start of an incident. On a day like July 24, the difference between a five minute and a twenty minute response can be the difference between a minor blip and a trending outage.
A tool like Pagerly, which is built to run on-call and incident management natively inside Slack, helps in a few concrete ways during exactly this kind of event:
None of this fixes AWS's network. What it does is compress the human latency in your response so that when an upstream dependency fails, your team is detecting, declaring, and communicating within minutes instead of waiting on a status page that will not update for the better part of an hour. The whole philosophy behind a Slack-native on-call tool is to meet responders where they already are and remove the coordination tax that makes incidents drag on.
The July 24 AWS us-west-2 outage will get a formal post-incident report from AWS in the coming weeks, and it is worth reading when it lands. But you do not need to wait for it to take the practical lesson. The providers you depend on will have bad days. Some of those days will be short, like this one. Some will be longer. In every case, the quality of your users' experience depends far more on how quickly and cleanly your own team responds than on how fast the vendor fixes its hardware.
The teams that came out of July 24 looking good were not lucky. They had invested in leading signals, they trusted their own telemetry over an external dashboard, they declared early, and they had a coordination process that let the right people move fast. Cloud outage response is a discipline, and it is one you can build before the next incident rather than during it. Take an hour this week to check three things: whether your alerts fire on user-facing symptoms, whether your on-call escalation actually reaches a human quickly, and whether your team knows where and how to coordinate the moment an incident is declared. Those three answers will matter far more than any status page the next time a dependency has a bad morning.
