Capital & Compute

Did AI-Generated Code Cause the Microsoft 365 Outage?

No evidence so far. Microsoft blames servers failing health checks and is reverting a network config change. Nothing ties the 12 Nov outage to AI code.

· ai· coding-agents· outages· microsoft· By Capital & Compute
Microsoft data center buildings at Middenmeer in the Netherlands behind a perimeter fence
Photo: Microsoft Data Center Middenmeer, the Netherlands - 2 by Hay Kranen, CC BY 4.0, via Wikimedia Commons. Cropped.

There is no evidence that AI-generated or “vibe-coded” code caused the Microsoft 365 outage of 12 November 2026. Microsoft blames servers that failed automated health checks and is reverting a recent network configuration change. It has not confirmed a root cause.

What caused the Microsoft 365 outage on 12 November 2026?

Microsoft’s explanation changed several times over the first twelve hours, which is normal for a live incident. Its broader Microsoft 365 incident began at 1:26 PM ET (18:26 UTC) on Thursday 12 November, according to BleepingComputer’s running report (Lawrence Abrams, 2026). Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot and Defender XDR were all listed as affected.

The first explanation was elevated load across several regions. Microsoft then corrected itself in a Microsoft 365 Status post on X: the load “isn’t driven by an increase in traffic, but by a number of servers being unexpectedly unavailable; straining the remaining infrastructure.” SecurityWeek (2026) reported that the affected servers were failing automated health checks, so they were pulled out of rotation and their work landed on the servers left standing. Later, Microsoft’s status page said “a process on the affected servers responsible for establishing secure connections becomes overwhelmed”, as reported by Gizmodo (Tom McKay, 2026).

The timeline below is in UTC. The intermediate timestamps come from an unbylined compilation of Microsoft’s admin-centre and X updates on azureblog.co.uk, cross-checked against the outlets above.

  1. 12 Nov, about 18:00

    Outlook reports peak

    Downdetector reports for Outlook peak near 130,000 (third-party data, not a Microsoft figure).

  2. 12 Nov, 18:26

    Incident MO1550821 opened

    Microsoft cites elevated load across multiple regions and begins restarting servers and moving traffic.

  3. 12 Nov, about 19:06

    Deployments paused

    Microsoft pauses all deployments and configuration changes while it reviews recent changes.

  4. 12 Nov, about 19:57

    "Not identified any recent change correlated"

    Microsoft says no recent change lines up with the start of impact and suspects a health-check component.

  5. 12 Nov, about 20:56

    Alternative health check validated

    A different health-check method lets some servers return to service.

  6. 12 Nov, evening

    Config updates under review

    Microsoft assesses whether reverting "the small number of recent configuration updates we identified" could speed recovery.

  7. 13 Nov, overnight

    Network change being reverted

    Microsoft has "begun reverting a recent network configuration change that correlates with the start of impact" and is limiting some traffic types.

  8. 13 Nov, morning

    Still not resolved

    Microsoft says a change "is not taking as expected"; recovery is partial and no root cause is confirmed.

Two statements in that sequence look contradictory and are worth reading carefully. Early on, Microsoft said it had not found a change that correlated with the start of impact. Overnight, it said it was reverting one that does. The quotes come from ABC News Australia’s live blog (2026), and SecurityWeek reported the same rollback. The most likely reading is that the review found something the first pass missed. Correlation is still not cause, and Microsoft has said nothing about who or what wrote that change.

Is there any evidence AI-generated code was involved?

None. Every Microsoft statement quoted above talks about servers, health checks, load, a connection-handling process and configuration changes. None mentions code authorship, and none mentions AI tooling. Microsoft also said there was “no indication” of malicious activity.

The AI-code theory spread anyway, and its path is easy to trace. Under BleepingComputer’s report, a reader comment linked Microsoft’s layoffs and its AI push to the outage and asked whether “AI-generated code, poor testing” was to blame. That line has since been repeated as if it came from the article. It did not. In Microsoft has suffered a global outage. A tech expert explains what went wrong (The Conversation, 2026), Mahmoud Elkhodr of CQUniversity Australia argues that “outages of this scale are more often self-inflicted” than the work of attackers. He makes no claim about AI-written code.

“Self-inflicted” and “AI-written” are different claims. A bad configuration push, a broken health probe or an overload feedback loop are all self-inflicted, and none of them needs an AI model to happen.

How much of Microsoft’s code is written by AI?

Enough that the question is not silly. At Meta’s LlamaCon on 29 April 2025, Microsoft CEO Satya Nadella said “maybe 20 percent, 30 percent of the code that is inside of our repos today” was “written by software”, as reported by TechCrunch (2025). TechCrunch noted it was unclear how Microsoft measured that, and the figure is now more than eighteen months old.

There are also signs that AI-assisted coding is straining Microsoft’s own processes. In September 2026, The Register reported (Simon Sharwood, 2026) that the Edge Add-ons team said AI-assisted coding had raised submission volumes and its “review pipeline has experienced additional strain”. The same piece recalled that the Exchange team had said AI tools found so many bugs it had not had time to ship a Cumulative Update. Both are about review load and bug volume, not about AI code breaking production.

The sharpest critique comes from a former Azure Core engineer, Axel Rietschin, whose essays Windows Central summarised (2026) under a headline blaming AI. Most of his specific complaints are older: a rushed launch, a talent exodus and weak testing discipline. That is one person’s account, and it predates this incident.

Have AI coding tools caused outages before?

AI has shown up in recent outage stories, but mostly as load rather than as bad code. GitHub’s own GitHub availability report: May 2026 (Jakub Oleksy, GitHub, 2026) says “GitHub’s traffic is growing rapidly, driven in large part by AI-assisted and agentic development workflows”. That is a capacity problem: agents opening pull requests and running CI at a scale the platform was not built for.

The large outages people remember predate AI coding tools. The July 2024 CrowdStrike crash came from a faulty content update (Wikipedia summary of the 2024 CrowdStrike outages, secondary), and an Azure DevOps outage in Brazil was traced to a single typo in code, as reported by TechRadar. When Microsoft publishes a review for this one, a configuration-change cause would fit that long pattern far better than an AI-code cause would.

This site covers the guardrails that make agent-written changes safe to ship: deny rules, sandboxes and tests that run before anything merges. See the agent harness checklist and the Claude Code autonomous workflow guide. Those controls apply to any change, whether a person or a model wrote it.

What would prove or rule out AI code as the cause?

Microsoft’s post-incident review is the only document that can settle this. For Microsoft 365 incidents of this size it usually arrives as a preliminary report in the admin centre within days, followed by a final version. Read it for four things:

  1. The triggering change. Was it the network configuration change being reverted, a code deployment, or neither? A pure configuration change makes the AI-code question moot.
  2. How the change was authored and reviewed. Reviews rarely say whether a tool helped write a change. If this one does, that would be news. If it does not, the question stays open, and nobody should fill the gap with a guess.
  3. Why the health checks failed. A probe that misreads a slow server as dead, then shifts its load onto healthy ones, is a classic cascading failure. That is a design question, not an authorship one.
  4. Why the fix did not hold. Servers that went unresponsive again once traffic returned point to a feedback loop. The review should explain what broke it.

What is confirmed, what is not

Claim Status Source
Outage began 12 Nov 2026, 18:26 UTC (1:26 PM ET) Confirmed by Microsoft advisory BleepingComputer, SecurityWeek
Extra load came from servers dropping out, not more traffic Microsoft statement Microsoft 365 Status on X
Servers failed automated health checks Microsoft statement SecurityWeek
Secure-connection process on servers became overwhelmed Microsoft statement Gizmodo (quoting Microsoft status page)
A recent network configuration change correlates with the start Microsoft statement, not a root cause ABC News live blog, SecurityWeek
No sign of a cyberattack Microsoft statement SecurityWeek
AI-generated code caused the outage No evidence; speculation only Reader comments, social posts

Frequently asked questions

Did AI-generated code cause the Microsoft 365 outage?
There is no evidence it did. As of 13 November 2026 Microsoft blames servers that failed automated health checks and an overwhelmed secure-connection process, and it is reverting a network configuration change that correlates with the start of the outage. No Microsoft statement mentions AI-written code.
What caused the Microsoft outage on 12 November 2026?
Microsoft has not confirmed a root cause. It says servers became unavailable after failing health checks, which overloaded the rest, and that a recent network configuration change lines up with the start of impact.
Was the Microsoft 365 outage a cyberattack?
Microsoft says there is no indication of malicious activity.
How much of Microsoft’s code is written by AI?
In April 2025 Satya Nadella estimated 20% to 30% of the code in Microsoft repositories was written by software. Microsoft has not said how it measures that.

Sources

Get each breakdown before it makes the rounds

You get one email when a new source-backed analysis goes live: what AI agents actually cost, which models are worth running, and what the benchmarks really mean. No hype.

No spam. Unsubscribe anytime.

← Back to Coding agents