iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Wikimedia said activity it believed came from OpenAI-operated agents may have contributed to a partial outage of Wikidata Query Service (WDQS) in May 2026. The disruption affected a data-query service, not all of Wikipedia. The May incident report describes aggressive scraping and service overload but does not identify OpenAI as the scraper, so the Foundation’s later attribution is not proof that OpenAI alone caused the outage.
What Wikimedia disclosed
On 5 October 2026, Wikimedia Foundation executive Selena Deckelmann said the Foundation had investigated activity on its platforms that it believed was from OpenAI-operated agents. The Foundation described three kinds of activity: edits to Wikimedia wikis, unsuccessful attempts to use public Etherpad to fetch data from other websites, and high-volume automated requests to public APIs, crawled pages and WDQS.
Wikimedia said the high-volume traffic may have contributed to the May WDQS outage. It also said none of the wiki edits were published to pages visible to general readers and almost all were testing edits in wiki sandbox areas. Wikimedia’s disclosure is the source for the agent attribution and its description of the activity.
Free tools Windows power users keep installed
One-click scans. No signup required.
What went down—and when
Wikidata Query Service lets people query Wikidata, Wikimedia’s structured-data project. The disruption was to this query service, not a report that Wikipedia as a whole went offline.
#1 Best Overall
The separate Wikimedia Wikitech incident report dates the disruption from 7 May 2026 at 15:10 UTC to 11 May at 13:50 UTC. It says aggressive scrapers began hitting WDQS on 7 May. Load on Blazegraph, the service’s query engine, led to timeouts; throttling of the streaming updater also contributed to rejected index updates and growing data lag.
At the peak, more than 50% of requests to the external WDQS endpoint timed out, and data on six nodes was stale for more than 20 hours. After a deeper log review revealed a scraper missed by sampled web-request analysis, Wikimedia applied a rate limit; timeout rates returned to baseline after that rule was applied. The incident report documents the technical disruption, but it does not name OpenAI or independently confirm the Foundation’s later attribution.
Rank #2
What the evidence does—and does not—establish
The two Wikimedia accounts address different questions. The October disclosure attributes activity to agents the Foundation believed were OpenAI-operated and says their high-volume requests may have contributed. The May incident record explains how scraping overloaded WDQS and provides service-impact details, but does not identify who operated the scraper.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
That distinction matters: the available statements support a possible contribution, not a confirmed finding that OpenAI caused the outage by itself. Wikimedia also said it found no evidence that its systems or data had been compromised, or that its systems had been used to coordinate agents. Deckelmann wrote: “We did not find any evidence that our systems were used for coordination among agents, nor did we find any evidence of our systems or data being compromised.”
Rank #3
What Wikimedia and OpenAI said
Wikimedia said it was concerned about the difficulty of attributing automated activity and the burden it places on volunteer editors and infrastructure teams. It also raised broader concerns about agent activity on public platforms.
In a 5 October report, CNA said OpenAI appreciated Wikimedia’s “detailed findings” and was working with the Foundation to analyze the activity. OpenAI spokesperson Drew Pusateri told CNA: “We’ll continue to share relevant information as that work progresses.” That is the response reported that day; it does not establish the eventual outcome of the review.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why automated traffic can affect Wikimedia services
Wikimedia’s 2025 explanation of crawler traffic provides broader operational context, not proof about the cause of this particular outage. The Foundation reported that bandwidth used to download Wikimedia multimedia had increased 50% since January 2024, and that at least 65% of resource-consuming traffic reaching its core datacenters was from bots. Those figures concern broader traffic patterns, not specifically the May 2026 WDQS incident.
The Foundation has explained that crawlers often request less popular pages, which are more likely to need service from core datacenters. Automated requests can therefore consume capacity that would otherwise be available to human visitors. Wikimedia’s October disclosure also noted the scale of its projects: more than 67 million Wikipedia articles across over 300 languages, and up to 15 billion page views per month. Those figures describe the platform’s scale, not a measure of the May outage.
Sources: Wikimedia Foundation disclosure, 5 October 2026; Wikimedia Wikitech WDQS incident report, last edited 15 May 2026; Wikimedia Foundation background on crawler operations, 2025; CNA report, 5 October 2026.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
