IMMUNO.OPS
Field Notes · Incident Analysis
On September 3, a failure in the Azure East US region took down three competing AI products at the same time. Thirteen days later, no public technical explanation has been published. The problem isn't a lack of communication. It's a dependency nobody had mapped.
At 10:58 UTC on Thursday, September 3, engineers started seeing the same pattern across completely different products, from companies that compete with each other every day. Over the next two hours, ChatGPT and Codex (OpenAI), Claude (Anthropic), and Grok (xAI) all reported instability at the same time. Grok stayed down the longest: 3h37m of documented disruption. [1]
The common cause, according to industry reporting, was an ingress failure in the Azure East US region: the same physical infrastructure behind products that, to the end user, look completely independent. [2]
Here's what Microsoft has published, officially, about the root cause as of this writing:
"No public technical explanation of the root cause."Summary of what Microsoft disclosed about the incident, thirteen days later
OpenAI, at least, updated its status page with some technical detail: elevated errors across 15 ChatGPT components and 4 Codex components. [1] Anthropic and xAI confirmed the instability in Claude and Grok, without detailing the mechanism. None of the four companies involved, Microsoft included, has published a complete root cause analysis to date.
Two weeks ago, we wrote about a Google Cloud outage with no real explanation: 4h08m, 15 products, a vague sentence as the official cause. This week the pattern repeats, just at a different scale. There, it was one company depending on a cloud it had chosen itself. Here, it's three competing AI products, used by millions of people every day, going down together because they share a dependency that, apparently, not even the providers themselves saw clearly.
The most telling detail of the incident is what didn't go down: Google's Gemini stayed largely stable through the whole window. Not because it's technically superior, but because it runs on its own infrastructure, outside Azure. [2] In this case, resilience didn't come from better architecture. It came from being somewhere else.
Why this keeps happening: most observability stacks audit what's inside their own cloud account. Few actually map which third-party services and which physical regions sit behind the products they use. Without that map, redundancy becomes theater: you can have three different AI vendors in your stack and still have a single point of failure, if they all run in the same region of the same cloud.
None of the companies involved has disclosed an official cost for the incident. What exists are aggregated user reports, collected by independent trackers during the instability window: an approximate but real picture of the scale of the problem.
Aggregated report numbers from independent third-party trackers, not official data disclosed by the companies involved.
Almost no observability stack puts the real dependency map and the cost of what happens when one of those dependencies fails side by side. The incident shows up on the status page. The shared dependency, when it surfaces at all, surfaces later, in an investigative report, not in an internal dashboard.
Closing that gap isn't about having more dashboards. It's about a different chain of reasoning, done automatically:
That's exactly the chain most postmortems skip, handing over a one-line summary instead. And it's the chain we're building at Immuno Ops: root cause and cost on the same screen, for Kubernetes environments, so that "no explanation at this time" stops being an acceptable answer.
We're not live yet. Beta opens later this year. If mapping real dependencies before the next collective outage is something your team needs, follow along.
Notify me at launch