Three outages in the last ten days, at AWS, Microsoft Azure and Anthropic, had the same odd shape. Whatever was already running kept working. Whatever tried to start fresh (a new EC2 instance, a restarted backend node, a user signing back in to Claude) ran straight into the broken part. In all three, the move you'd normally reach for first during an incident was the one that didn't work.
AWS EC2: Running Instances Fine, New Ones Couldn't Launch
On the afternoon of September 21, Pacific time, EC2 in us-east-1 spent about 77 minutes failing new instance launches. AWS put it down to "a recent deployment to a subsystem within the EC2 service responsible for processing instance launch requests," and rolled that deployment back. Instances that were already up were never affected.
That sounds like the gentle kind of outage until you list what depends on launching. Auto Scaling groups replacing unhealthy hosts, ECS and Fargate starting new tasks, EMR bringing up clusters: AWS named ECS, Fargate and EMR as impacted. A service that was healthy when the window opened stayed healthy only as long as nothing about it had to change. If a host died, or traffic climbed and the autoscaler went to add capacity, the replacement never arrived. A team shipping a deploy onto fresh nodes in that window would reasonably have concluded their own release was broken, when the problem sat a layer below them. The trigger itself was a deployment, which is the kind of routine change that keeps causing the worst outages, even at the companies with the most practice shipping them.
https://awsdown.com/incidents/evt-AWS_EC2_OPERATIONAL_ISSUE_79073_047629764F9
Azure OpenAI: A Health Check That Restarted the Survivors
From 10:03 to 15:58 UTC on September 29, Azure OpenAI Service, Foundry and Cognitive Services in Sweden Central saw intermittent failures, higher latency and 5xx errors. Microsoft's preliminary review traces it to a backend service that looks up resource metadata. "An internal system process generated an increase in the overall amount of requests" to that service, its instances hit their utilization thresholds, and they began restarting. Then the automation joined in: "An automated health check then triggered additional restarts, further reducing the number of healthy instances available to process requests."
Every restart took an instance out of the pool and moved its share of the load onto the rest, which pushed those over the threshold in turn. The health check was doing its job, removing sick instances, but the sickness here was load, and when the problem is load, pulling instances out only concentrates it. Engineers got out of it by scaling the service out and raising its resource limits, and Microsoft's follow-ups focus on throttling and rate-limiting internal processes. It's a close relative of the retry storm in the first Roundup, where the recovery mechanism was also the amplifier.
https://azure.status.microsoft/en-us/status/history/?trackingId=7QL5-Z50
Claude: "If You're Signed In, Please Don't Sign Out"
The same day, Anthropic's status page reported elevated errors across claude.ai, the API, Claude Code and Cowork beginning at 14:00 UTC. The main errors were mitigated by 14:36 and existing conversations mostly came back, but sign-in stayed broken for longer: single sign-on and Apple login kept failing, along with new chats, Claude Code and Cowork sessions, and file uploads. Anthropic's update told users plainly, "If you're signed in, please don't sign out."
Anthropic hasn't published a root cause, so I won't guess at one. What's worth noticing is the advice. A live session was the thing still working, and the standard fix for a flaky web app, signing out and back in, would have thrown it away. Most status pages say what's broken and stop there. Very few tell users which of their own actions are safe mid-incident, and this one did. If part of your system can still serve people who already hold a session, a token or an open connection, say so on the status page.
https://9to5google.com/2026/09/29/claude-confirmed-outage-sept-29/
What the Three Have in Common
Restart it, scale it out, log back in: most incident reflexes quietly assume that the path for creating something new is healthier than the thing that's struggling. In these three incidents it wasn't. Launch requests, health-check restarts and sign-in are all ways of starting from scratch, and starting from scratch is what broke.
Two checks follow from that. First, go through your runbooks and mark which recovery steps depend on a control plane you don't own. If step one is "replace the node," write down what you'll do when the provider's launch API is the thing failing. Second, put limits on your own automation. A health checker or autoscaler that can cycle half your fleet in a few minutes is, under overload, a way to make the overload worse, and capping how many instances it may act on at once costs very little.
Monday's issue argued that most of the time in a software outage goes into working out what broke. Recovery steps that silently fail are one of the ways that time stretches out. Picture a team spending twenty minutes wondering why new pods won't schedule before anyone thinks to check whether the cloud can launch a VM at all.