What public incident reports tell us about AI, outages, and the systems we depend on.
We have all seen the headlines lately: critical vulnerabilities in PHP, major services unavailable, and the Microsoft 365 disruption on November 12–13 affecting tools we use every day. In the latest report as of the writing of this article, Microsoft reported recovery progress, although some users still experienced intermittent issues. We cannot attribute the incident to AI.
The broader question is still worth asking. As AI takes on more coding and operational work, is it contributing to the problems we keep reading about?
Following the incident reports led me to several different answers. In one case, AI helped expose weaknesses that had existed for years. In another, an engineer followed inaccurate AI advice. Other failures involved infrastructure problems whose published accounts did not establish a generative-AI cause. Putting them together under “AI is breaking things” would hide much of what we could learn from them.
PHP had a problem before AI found it
On October 21, the PHP maintainers disclosed critical vulnerabilities that could allow attackers to execute code without logging in. PHP released security updates addressing the vulnerabilities that day and urged users of affected versions to update. The weaknesses were in the runtime beneath applications, so an organization could be exposed even if its own developers had written their application carefully.
According to Wiz’s research account, AI models helped researchers uncover longstanding flaws and build working exploits. The researchers describe problems rooted in decisions made years earlier, with models making difficult investigation and exploit development more practical.
For those of us reading the news, the software suddenly looked more dangerous. The weakness, however, was already there. Finding it created an opportunity to fix something that had survived previous scrutiny.
That opportunity came with urgency. On November 12, Check Point reported exploitation against unpatched gateways, describing attacks beginning October 30 and a broader wave on November 2. Its account says attackers used PHP2Shell for initial access and a separate vulnerability to gain greater control.
The report does not establish that those attackers used AI. What it does show is the work facing defenders after disclosure: identify affected systems, establish who owns them, and get the fixes deployed. Discovering a flaw is valuable; an organization still has to act on the discovery.
An old wiki can become new advice
The AI connection was different in a March 2026 statement from Amazon. Responding to coverage of incidents in its retail infrastructure, the company disputed claims that AI-written code had caused the outages. It said one incident involved an engineer following inaccurate advice an AI tool inferred from an outdated internal wiki.
Amazon said the cause was unrelated to AI, attributing the incident to an engineering error whose effects its systems failed to contain. It said none of the incidents involved AI-written code, and all concerned retail infrastructure rather than AWS.
The wiki detail is useful because it makes the risk easy to picture. Consider an assistant recommending a procedure that worked in an earlier version of a system. The answer may sound specific and credible because it draws on internal documentation. Someone still needs to check whether the procedure applies to the environment in front of them.
Connecting an assistant to company knowledge therefore creates a maintenance obligation. Someone has to own the information it consults. A document that a colleague might recognize as obsolete can otherwise arrive as a fresh recommendation, stripped of the context that would have prompted a second look.
This is also why checking generated code alone would miss part of the problem. AI can influence a consequential decision without writing the software involved.
What happens when the rest of the process cannot keep up?
There is broader evidence worth considering here. DORA’s September 2025 research found positive associations between AI adoption and delivery throughput, alongside a negative association with delivery stability. It was organizational research, so those associations cannot establish the cause of a particular outage.
For a team adopting AI, though, the finding suggests a useful place to look. A developer may produce changes faster while the same reviewers still have the same hours available. Tests may cover the familiar paths and miss the unusual conditions a larger volume of changes introduces. Faster implementation leaves those constraints in place.
I would want to see what happens after the code is generated. Are changes waiting longer for review? Is the team spending more time correcting releases? Can it reverse a deployment promptly when something goes wrong? Those answers tell us more about delivery than the number of suggestions accepted from a coding assistant.
One incident can reach several tools
AI is only part of the reliability question. The infrastructure underneath our tools deserves just as much attention.
In its October 2025 DynamoDB post-event summary, AWS described a timing problem in automated DNS management that left a regional endpoint without the addresses needed to reach it. Dependent services were affected, and fixing that initial problem did not immediately complete recovery.
Cloudflare’s account of its November 2025 outage describes a database-permissions change that produced an oversized file used by Bot Management. Distributing that file caused failures across its network. The company ruled out malicious activity.
These accounts describe specific infrastructure failures; neither establishes generative AI as the cause. They also explain why a single incident can produce so many recognizable names in our feeds. We may use different applications without realizing that they depend on the same underlying service.
Even an AI product’s involvement needs closer examination. In GitHub’s account of its August 17, 2026 outage, a capacity failure started the disruption, while a Copilot client retry loop added traffic during recovery. The distinction between starting a failure and making recovery harder matters when deciding what to fix.
Are failures actually becoming more frequent?
The headlines alone cannot answer that. The public findings from Uptime Institute’s 2026 outage analysis suggest that outage frequency per site declined for a fifth consecutive year, although the improvement slowed. They also identify a greater prominence of external infrastructure failures in publicly reported incidents.
That research concerns IT and data-center outages, rather than every SaaS interruption or security breach. It nonetheless challenges the assumption that all reliability measures must be getting worse.
We can hear about more incidents without knowing whether the rate has increased. A weakness newly discovered in old software, an outage affecting several applications, and a successful attack are different events. Counting their headlines together tells us little about how often a particular system fails.
For now, the evidence supports specific concerns about AI’s role. It does not establish that AI is responsible for a general increase in outages.
The next advisory will still need an owner
Looking ahead, the UK’s National Cyber Security Centre expects AI to make parts of cyber intrusion more effective through 2027, including vulnerability research and exploitation. Its assessment anticipates further pressure on the time organizations have to address disclosed weaknesses. This is a forecast, and the same capabilities can also help defenders find and repair flaws.
For managers, that makes some ordinary operational questions more urgent. When an advisory arrives, can someone determine whether we are exposed? When an assistant recommends a production change, who checks the current procedure and the proposed action? If our usual email or identity service is unavailable, can the team still coordinate recovery?
These are worth testing before the next incident. Pick a critical workflow, trace its dependencies, and rehearse what happens when one is unavailable. Review the permissions given to AI tools as carefully as the actions people take on their advice.
I would keep asking whether AI contributed whenever a failure is investigated. An answer such as “an engineer followed advice based on an obsolete runbook” gives a team something concrete to address. So does a finding about retries, capacity, or deployment controls. The broad label “AI failure” tells us much less.
This article discusses publicly documented incidents and research available as of November 13, 2026. AI tools assisted with research and drafting; I chose the topic and editorial direction. Sources are linked throughout.
