Three unrelated companies went down this month, and in every case the failure wasn't where you'd expect to find it. Salesforce's outage wasn't caused by Salesforce's application layer — it was an internal login service running out of room. Microsoft's two-day outage wasn't Exchange Online's mail pipeline — it was an authentication configuration a few layers underneath it. Google Cloud's four-hour blackout wasn't a bad deploy — it was one maintenance ticket carried out too literally. Different companies, different root causes, same shape: the thing that took the platform down was never the thing with its own icon on the architecture diagram.
Salesforce: An Internal Login Service Ate the Whole Platform
On September 16, Salesforce's core platform went dark for roughly 10.5 hours across hundreds of Hyperforce instances worldwide — during Dreamforce, the company's own flagship conference. Salesforce's own explanation was specific: requests were "stalling while waiting on a response from an internal login service, which is using up available server resources." That single stalled dependency was enough to limit the platform's capacity to process any incoming request, not just logins — support-case creation, the Marketing Cloud preferences page, and API traffic all degraded alongside it. Recovery took a phased fleetwide fix plus manual restarts on instances where the automated rollout didn't finish the job. One detail worth sitting with: GovCloud, Salesforce's isolated environment for US government customers, stayed up the entire time — not because it's more resilient by design, but because it doesn't share the same internal login service the rest of the fleet does.
Microsoft 365: A Two-Day Outage Traced to Authentication Configuration
Starting August 31 and not fully resolved until September 3, Exchange Online and everything hung off its identity layer — Teams, SharePoint Online, OneDrive for Business, Copilot, Universal Print, Defender XDR — degraded or failed for more than 48 hours. Microsoft eventually traced the pattern to "core authentication configuration issues used by multiple internal services within the Exchange Online infrastructure," later noting the affected footprint was "less than one percent" of its infrastructure. That's the part worth underlining: a misconfiguration confined to under 1% of the fleet still produced a two-day, multi-product outage, because so much else authenticates through that same layer. Size of blast radius and size of root cause weren't related at all here — our take on performance failures that don't trip the usual alerts covers a related version of this mismatch, where the thing that breaks isn't sized the way your monitoring assumes it will be.
Google Cloud: One Technician, 13 Minutes, and Every Fiber Path Unplugged
On September 1, a routine hardware maintenance procedure in the us-central1-b zone took multiple Google Cloud products offline for about four hours and eleven minutes, with traffic drop rates hitting 100% for affected resources. Google's own incident report is unusually blunt about the cause: a technician was supposed to disconnect fiber paths one router at a time, preserving redundancy throughout; instead, "a procedural error meant that the physical maintenance action sequentially unplugged 100% of fiber paths across all devices within 13 minutes." Nineteen products — Compute Engine, GKE, Cloud SQL, BigQuery, Spanner, and more — degraded as a result. What makes this one sting is that Google's infrastructure is explicitly built with "redundancy across multiple routing devices" and diverse power sources specifically so that single or multiple device failures don't reach the customer. That design assumption held right up until a human, in 13 minutes, removed all the diversity the redundancy depended on. We wrote about this exact gap between redundancy on paper and the actual failure domain a few weeks back — this is that pattern again, just with the human as the failure domain instead of a shared rack or region.
The Pattern, Not the Coincidence
To be clear about what these three don't share: no common vendor, no shared timing, no upstream dependency linking them the way three separate incidents turned out to share a single point of failure a few weeks ago did. These aren't connected the way that piece — or last week's look at teams wrongly assuming simultaneous outages must be related — warns against inferring. They're just three independent companies that each learned the same thing in the same month: a login service, an auth config, and a maintenance runbook aren't the product, but they're load-bearing for it anyway.
If your team's incident-response investment is organized around the customer-facing surface — the API, the app, the dashboard — none of these three would have shown up on your radar until users were already locked out. The fix isn't "add more redundancy." All three companies already had plenty. It's auditing what's authenticating, routing, or resourcing your actual product, and naming who owns watching that layer specifically, not just the thing it happens to support. Salesforce and Microsoft can't blame an upstream vendor for this one. Neither can Google. The failure was in-house every time — which is exactly why it's worth reading closely instead of filing under "someone else's problem."