On the morning of July 24, 2026, a large slice of the internet blinked out at once. An AWS outage centered on the US-West-2 region in Oregon rippled outward and took DoorDash, Reddit, Hulu, Apple Pay, Snapchat, Fortnite, and the PlayStation Network offline for millions of users. If your team runs anything on Amazon Web Services, this is the incident to study, because the hard part was never fixing AWS. The hard part was AWS outage incident response: knowing within minutes that the problem was upstream, keeping your on-call engineers from chasing ghosts in your own stack, and telling customers something true while the provider status page was still catching up.
This post breaks down what happened, why a single region can knock over so many household names, and how to run a calm, fast incident when the root cause sits inside someone else's data center. The goal is practical: a playbook you can adopt before the next provider outage, not a retrospective that only makes sense after one.
According to outage trackers and reporting, the disruption began around 6:40 a.m. ET and was concentrated in AWS US-West-2, the company's large Oregon region. AWS confirmed it was investigating connectivity problems, initially flagging issues with roughly five services before expanding the list to seven, including Global Accelerator and Elastic Container Service. Downdetector-style monitors logged reports across 74 cities in 20 countries.
The consumer-facing damage was immediate and very visible. Reddit threads filled up with people asking whether Apple Pay was down at checkout. Gamers could not sign in to PlayStation. Food sat in DoorDash carts that would not submit. The through line was not that all of these companies failed at the same moment by coincidence. It was that they share infrastructure, and when the shared layer degrades, every tenant on top of it feels it at once.
What makes a provider outage different from a normal production incident is the blast radius. When your own service breaks, the impact is bounded by your customer base. When a hyperscaler region degrades, the impact is bounded by everyone who happens to depend on that region, directly or through a vendor. A payments provider you rely on might be down. A CDN edge might be slow. An authentication service you never think about might be timing out. Your users experience all of that as your product being broken, even when your code never changed.
This is why the July 24 event is worth a careful look. The engineering teams that came out of it looking competent were not the ones with magic infrastructure. They were the ones whose incident response recognized the pattern quickly and communicated clearly while the fix was out of their hands.
Cloud regions are marketed as isolated failure domains, and to a large degree they are. The problem is concentration. Many organizations run the bulk of their workloads in one or two favorite regions because latency, data residency, and cost all push toward consolidation. US-East-1 in Virginia is famous for this, but US-West-2 carries a similar load for a huge number of West Coast and globally distributed companies. When a region that dense has a connectivity or control-plane problem, the visible internet takes a hit that looks far bigger than the underlying fault.
There is also a dependency-chain effect. Service A depends on a queue in the affected region. Service B depends on Service A. A status dashboard depends on Service B. One connectivity fault at the bottom cascades into a dozen unrelated-looking symptoms at the top. For an on-call engineer staring at a wall of red, the first job is not to fix anything. It is to figure out how deep the real problem is.
It is tempting to treat a provider outage as someone else's job. AWS broke it, AWS will fix it, so the thinking goes, and there is nothing to do but wait. That framing is wrong, and it is expensive. During a provider outage your team still owns three things that matter enormously.
You own diagnosis. Nobody paging into your incident channel knows for the first several minutes whether the outage is yours, a dependency's, or the cloud provider's. Every minute spent chasing a phantom deploy or rolling back healthy code is a minute added to your effective mean time to recovery. Fast, correct attribution is real incident work.
You own customer communication. Your users do not have an AWS support contract. They have you. What you post on your status page and how quickly you post it shapes trust more than the outage duration itself. Silence during a widely reported outage reads as incompetence even when you did nothing wrong.
You own partial mitigation. Even when the root cause is upstream, there is usually something you can do: fail over to another region, degrade gracefully to a read-only mode, disable a non-critical feature that is amplifying load, or reroute traffic away from the affected dependency. None of that happens automatically. It happens because a prepared on-call responder knew the option existed and had the authority to pull the lever.
The best AWS outage incident response looks boring from the outside because the team has removed improvisation from the moments that matter. Here is the shape of it.
The first signal is rarely a clean alert that says "AWS US-West-2 is degraded." It is a scatter of symptoms: elevated error rates, latency spikes, failed health checks, a jump in customer reports. The responder's job in the first five minutes is to answer one question: is this us or is this upstream? A good triage habit is to check a small set of external signals immediately. Look at the provider's status page, a third-party outage tracker, and your own dependency dashboards side by side. If multiple unrelated services degrade at the same second and your last deploy was hours ago, you are almost certainly looking at an infrastructure or dependency event, not a code regression.
Attribution speed is the single biggest lever on total incident cost. Teams that reflexively roll back or scale up in response to a provider outage often make things worse and always waste time. Teams that pause, correlate the timeline, and name the real cause move straight to mitigation and communication.
Once you know it is a provider event, the incident needs one place where the current state lives. Scattered DMs and side conversations are where incidents go to get slow and confused. You want one channel, one incident commander, one running timeline, and one canonical status that everyone reads instead of asking "what is the latest?" every ninety seconds. This is where a structured, chat-native incident workflow earns its keep, because the coordination happens in the same place your engineers already work.
During a high-profile outage, customers will forgive a lot if you keep talking. Decide your external cadence before the incident, not during it. A reasonable default is a first public acknowledgment within fifteen minutes of confirming customer impact, then updates on a fixed interval such as every thirty minutes even when the update is "still investigating, dependency is upstream." Internally, the incident commander should be pushing brief status snapshots on an even tighter loop so responders and leadership stay aligned without interrupting the people doing the work.
Most incident runbooks assume the fault is inside your systems. Provider outages need their own runbook, because the response is genuinely different. Here is what belongs in it.
You cannot reason about a dependency you have never mapped. Before the next outage, write down the external services that would take your product down if they failed: your cloud regions, your payments provider, your auth provider, your email and SMS senders, your CDN, your critical SaaS APIs. For each one, note where its status page lives and what your fallback is. When the July 24 outage hits and Apple Pay is timing out, you want the on-call engineer to open a document that already says "payments dependency, here is the status page, here is how we switch to the backup processor," not to discover the dependency graph live at 6:45 a.m.
Ambiguity is the enemy at 3 a.m. Decide in advance what severity a provider outage maps to, who gets paged, and when you escalate from a single responder to a full incident bridge with an incident commander. A useful rule is to tie escalation to customer impact rather than to root cause. A provider outage that takes checkout offline is a high-severity incident even though your code is fine, and it should page accordingly.
Multi-region failover and graceful degradation are only real if you have rehearsed them. A runbook step that says "fail over to US-East" is worthless if nobody has ever run it and it turns out the standby region is missing a config value. Game days and periodic failover drills are what turn a written procedure into something a tired on-call engineer can execute correctly under pressure.
The uncomfortable truth about a provider outage is that your mean time to recovery is partly gated by a vendor you do not control. That does not make MTTR irrelevant. It shifts where you can win. You cannot shorten how long AWS takes to restore US-West-2, but you can shorten every other segment of the incident timeline.
You can shorten time to detect with monitoring that watches dependency health, not just your own error rates. You can shorten time to attribute with triage habits and dashboards that make "us versus upstream" obvious in seconds. You can shorten time to communicate with pre-written status templates so the first customer update is a fill-in-the-blank, not a blank page. And you can shorten time to mitigate with rehearsed failover and clear authority to act. Add those up and a team can turn a chaotic hour into a controlled twenty minutes of customer-visible impact, even when the underlying fault lasts longer.
The teams that measure MTTR honestly know that the metric worth improving is not "mean time to page." Paging fast is easy. The metric that moves customer trust is mean time to a coordinated, communicated response, and that is entirely within your control regardless of whose data center caught fire.
Provider outages punish tool sprawl. When the internet is on fire, the last thing an on-call engineer needs is to bounce between a paging app, a separate incident tool, a status page editor, and three chat windows. The coordination cost of context switching during those first critical minutes is exactly where responses fall apart.
This is the case for keeping incident response where your team already lives. A Slack-native on-call tool like Pagerly puts scheduling, escalation, alerting, and incident coordination inside the channel where your engineers are already talking. When a July 24 style outage lands, the person on call gets paged in Slack, the incident channel spins up in Slack, the on-call schedule and escalation policy are visible in Slack, and the running timeline lives in Slack. There is no separate console to log into while customers are waiting. For teams that run their entire engineering culture in Slack, collapsing the incident workflow into that one surface removes a whole category of friction at the exact moment friction is most expensive.
The broader point is not about any single vendor. It is that your incident tooling should reduce cognitive load during an outage, not add to it. Whatever you use, the test is simple: when a provider outage hits and adrenaline is high, does your tooling get out of the way and let the team coordinate, or does it become one more thing to fight?
If you take nothing else from this incident, take these:
Concentration in a handful of cloud regions is not going away, which means outages like the one on July 24, 2026 are a recurring feature of running software on shared infrastructure, not a freak event. The companies that handle the next one well will not be the ones with the fanciest architecture. They will be the ones whose on-call practice already assumes that some incidents originate upstream, whose responders triage attribution before they touch a single deploy, and whose customers hear a clear, honest update while the fix is still out of their hands.
You cannot prevent your cloud provider from having a bad morning. You can absolutely decide how your team shows up when it happens. Build the dependency map, write the provider-outage runbook, rehearse the failover, pre-draft the customer updates, and put your incident coordination somewhere your engineers can act without friction. Do that, and the next AWS outage becomes a controlled, well-communicated twenty minutes instead of a scramble that costs you customer trust you spent years earning.