Three outages in the last two weeks share one pattern: the redundancy was real and well-designed, and the outage came through anyway — because it hit a layer the redundancy didn't cover. Google Cloud lost most of a zone to a fiber-maintenance procedure. Claude and Grok went down together because they share a building. A dozen Microsoft 365 products failed on one authentication config. Same instinct as Roundup #1 and #2: read each postmortem past the headline, and look for the shared thing nobody drew on the architecture diagram.
Google Cloud: Redundant Fiber Paths, One Maintenance Procedure
On September 1, part of the us-central1-b zone in Google's Iowa region lost external connectivity from 07:41 to 11:52 Pacific — just over four hours. Google's incident summary names the cause plainly: "the inadvertent physical disconnection of network fiber-optic cables during a routine hardware maintenance procedure." A procedural error during a scheduled capacity upgrade led an engineer to sequentially unplug every fiber path across all the devices involved, inside 13 minutes. Traffic drop rates for resources in the affected area reached 100% at the peak; virtual machines were simply unreachable. Nineteen products were affected, from Compute Engine and GKE to BigQuery, Spanner, and Cloud SQL. The fix was as physical as the cause: technicians reseated the optical fibers, and traffic shifted back to healthy capacity on its own.
Google builds redundancy across multiple routing devices and fiber paths, designed to ride out any single device or path failing. What that redundancy doesn't account for is a single procedure with reach over every path at once — the kind of low-drama routine change that causes a surprising share of serious outages. The paths were diverse; the maintenance operation running across them wasn't. Google has paused maintenance in the region pending audits and promised a full incident report — the thing to watch for in it is whether the tooling could have stopped itself once link loss started climbing across supposedly independent paths.
https://status.cloud.google.com/incidents/J5ia5t9p3g9Q5Wi7r8Ev
Claude, Grok, and ChatGPT: One Window, Two Different Causes
On September 3, Claude, Grok, and ChatGPT all degraded inside the same 90-minute window. The reflex when that happens is to reach for one shared cause — a common cloud, a CDN, an attack. This time two of the three plausibly did share one, and the third didn't.
xAI's explanation for Grok: "We are sorry for the issues you may have experienced with Grok following an outage at our Memphis compute center this morning" — and, notably, "we'd also like to apologize to our impacted compute partners." Claude had a three-hour, six-minute window of elevated errors on Sonnet 5 and other models, cleared at 16:16 UTC. Those two facts connect through a deal signed in May: Anthropic contracted the entire output of xAI's Colossus 1 datacenter near Memphis — 300 megawatts of compute — paying $1.25 billion a month through 2029. The Memphis site runs both xAI's own compute and the Colossus 1 capacity it now leases to Anthropic, so a site-level problem there reaches both tenants at once. That's why xAI was apologizing to "compute partners," and why The Register concluded the facility may have been a shared resource affecting Anthropic's service alongside Grok's.
ChatGPT is the counter-example. OpenAI's account: "A routing error starting around 7:43 am PT on Thursday, September 3 made ChatGPT and Codex unavailable for some users across platforms," resolved inside about half an hour. That was a fault in OpenAI's own routing — no Memphis, no shared datacenter, just timing that lined up with a much longer incident next door. During a multi-party outage, the correlation on your status board is not evidence of a common root; treating it as one sends you inspecting a dependency that's fine while your real fault sits unexamined. It's the same discipline as reading one incident across four monitoring tools — the views lining up doesn't make them right. "We use more than one AI provider" is also worth a second look here: it reads like diversification on a slide, but not if those providers sit in the same building, and compute is now scarce enough that they routinely sublease each other's capacity. The failure domain is the datacenter, not the logo on the contract.
Microsoft 365: A Dozen Services on One Authentication Config
On August 31, Microsoft acknowledged a Microsoft 365 incident — tracked as EX1464935 — that started around 17:30 UTC and, per reporting, took the better part of three days to fully clear. Exchange Online was hit hardest: failed sends and receives, mailbox-search failures, authentication errors. But the impact ran across Teams, Graph, Purview, OneDrive for Business, SharePoint Online, the 365 Admin Center, Copilot, Universal Print, and Defender XDR. Microsoft's stated cause was "core authentication configuration issues used by multiple internal services within the Exchange Online infrastructure" — a misconfiguration that stopped authentication components from deploying as expected to part of the fleet. Recovery meant re-applying those components across a sample of affected infrastructure, then expanding outward.
Each of those products has its own status page, its own team, its own on-call rotation. On paper they fail independently. They don't, because they sit on a shared authentication substrate, and when that substrate can't deploy cleanly, everything above it starts returning auth errors at the same time. It's the Memphis story one layer up the stack: the thing all these services have in common isn't on the diagram anyone pulls up during a design review.
The pattern across all three
Three different layers — physical fiber, a leased datacenter, an auth config — and the same gap in reasoning each time. The redundancy was built against one failure mode (a device dies, a provider has a bad day, a service crashes), and the outage arrived through a shared dependency one level down that the redundancy didn't span. Google's diverse fiber paths shared a maintenance procedure. Claude and Grok shared a building. A dozen Microsoft products shared an auth component. None of these are exotic — they're the ordinary result of drawing the dependency graph only as deep as the design conversation needed it to go.
The question each of these postmortems leaves you with isn't "do we have redundancy." It's "redundancy against what, exactly — and does it still hold one level below where we stopped drawing." That's usually where the shared failure domain is hiding: just past the edge of the diagram, in the thing everyone assumed was someone else's problem. A dependency you've never traced to the bottom is a single point of failure you haven't found yet.