Everyone knew why the AI went down. The status page did not.

Three incidents, one day, one borrowed explanation. What the primary source actually said.

What happened

On 12 and 13 November 2026 a large Microsoft outage disrupted Teams, Outlook and other services. Claude had problems in the same window. The explanation circulated fast: the AI broke because Microsoft broke.

It is a clean story. It is also partly assembled rather than reported.

So instead of reading the coverage, I read Anthropic's own status history. Here is what it records.

What the status history actually says

Incident 1 — "Elevated errors affecting the Microsoft 365 connector."
Activity from 12 November 17:52 UTC, resolved 13 November 21:49 UTC. The updates state a cause, verbatim:

We have identified an issue with an upstream provider affecting the Microsoft 365 connector.

This issue is caused by a Microsoft 365 service incident.

Incident 2 — "Elevated errors on claude.ai, Claude Code, and platform.claude.com."
13 November. The opening update:

We are investigating an issue with users authenticating to Claude.ai and Claude Code.

The resolution names no cause.

Incident 3 — a further incident later on 13 November. Also no cause stated.

So exactly one of the three carries an upstream attribution, and it is the connector — the feature whose entire job is reading Microsoft 365 data. That is the one you would expect a Microsoft outage to take down, and the vendor says so plainly.

The authentication incident has no published cause. The coverage gave it one, by borrowing from the incident sitting next to it on the same page.

To be precise about my own claim: I am not asserting the auth incident was unrelated to Microsoft. It may well have been. I am saying the primary source does not say so, and the difference between "unrelated" and "not stated" is the whole point.

Why this pattern repeats

During an incident, everything co-occurs. That is what an incident is. Co-occurrence is the background condition, not evidence.

The neighbouring incident is the cheapest available explanation, because it is the only one already written down. A cause that exists in text will beat a cause that requires investigation, every time.

Nobody re-reads the source once a cause is circulating. The explanation becomes infrastructure. I only caught this because I went looking for a primary citation for a different reason.

Teams then remediate the wrong dependency. This is where it stops being an epistemics problem and starts costing money. You harden the integration you believe failed, write a runbook for it, maybe add a fallback — and the thing that actually broke is untouched and will break again.

The real lesson, which is the less exciting one

Separate the invented cascade from the documented one, because the documented one is genuinely instructive.

A feature that reads a vendor's data inherits that vendor's availability. The M365 connector could not work while M365 was unwell, and no amount of engineering on Anthropic's side changes that. It is a correct, expected, unavoidable dependency.

The question that follows is the useful one: which of your features inherit which third party's availability, by name? Most teams have never written that down. They know their own uptime number and treat it as something they control, when a meaningful share of it is a product of other people's.

A simple version is enough to start:

feature depends on degrades to ----------------------------------------------------------------- invoice extraction our OCR + our model queue + retry GST portal lookup gov portal manual, flagged to user email drafting model API cached templates M365 document search Microsoft Graph unavailable, say so

That last column is the one people skip, and it is the one that decides whether an outage is an inconvenience or an incident.

The discipline

Read the vendor's own status page before accepting a cause from anywhere else. It takes two minutes. It is the entire difference between this post and the one I would otherwise have written.

Treat "stated cause" and "no cause stated" as different data. The second is not a gap for you to fill. It usually means the investigation is open.

On your own status page, write what you know. "Cause under investigation" is a complete sentence, and a more honest one than a plausible guess you will have to retract.

Two hard rules

Co-occurrence is not causation, and an incident is the moment co-occurrence peaks. The one time your instincts are least reliable is the one time everyone demands an immediate answer.

"No cause stated" is information. Do not improve it.

Honest limitation

I read Anthropic's public status history directly, and the quotes above come from it.

The Microsoft details — including a reported statement that the outage was not related to AI agents — and a separate aviation disruption that some coverage connected to an AI rollout on timing alone, I have not verified against those organisations' own statements. I am repeating secondary reporting there, and flagging it as such.

Root-cause reviews were still pending when I wrote this. Anything here may be superseded by them, and if it is, the correct response is to update rather than defend.