Three Ukrainian drone strikes hit Yandex data centers in Sasovo, Kaluga, and Vladimir between October 8 and October 11, 2026, and automated traffic from Yandex’s network collapsed in the days that followed. Cloudflare data cited by The Verge shows that traffic fell to roughly 57% of its prior two-week peak after the first strike, then dropped further to just 0.4% after subsequent attacks. Within hours, a theory took hold online: the strikes had knocked out a Russian bot farm, and the silence on social platforms was Ukraine’s drone fleet doing counter-disinformation work by accident.
That story is tidy, satisfying, and almost certainly wrong, or at least unproven. The data everyone is citing measures automated HTTP requests originating from Yandex infrastructure. It does not identify who was running those requests, what they were doing, or whether “bot” means a disinformation network, a web scraper, a search indexer, or an ad-fraud operation. Yandex is one of the largest internet companies in Russia, running everything from cloud hosting to ride-hailing to search. A drop in automated traffic from its network could mean a dozen different things, and right now nobody with on-the-record authority has said which one it is.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Actually Happened at Yandex’s Data Centers
According to reporting reviewed for this story, Ukrainian drones struck Yandex facilities in three Russian regions over a four-day span: Sasovo, Kaluga, and Vladimir. The Sasovo site reportedly housed two supercomputers, making it one of the more significant targets in the sequence. Each strike has been described separately in regional and trade press, and the pattern, three hits on the same company’s infrastructure inside four days, is itself notable regardless of what downstream effect it had on bot traffic.
Yandex operates critical infrastructure well beyond search. Yandex Cloud hosts enterprise workloads for Russian businesses, Yandex Go runs ride-hailing and delivery across multiple cities, and Yandex LLC covers the company’s broader consumer and advertising stack. When a facility goes down, the knock-on effects can touch services that have nothing to do with each other on the surface. That is part of why a single data point, a drop in automated traffic, has been stretched into a much bigger narrative than the underlying measurement supports.
The Cloudflare Numbers: 57% Down to 0.4%
The most frequently cited figures come from Cloudflare, which tracks traffic patterns across its global network and can break down requests by originating network. On October 8, 2026, automated HTTP requests attributed to the Yandex network fell to approximately 57% of their previous two-week peak. That alone would be a meaningful disruption. But the trend did not stop there. Later measurements, reported by outlets including RuntimeWire, showed the same traffic falling to just 0.4% of its prior peak, a drop of more than 99% from baseline.
Cloudflare’s classification system flags traffic as “automated” based on request patterns, headers, and behavioral signals, not based on intent or ownership. That distinction matters enormously here. A crawler indexing pages for Yandex’s search engine, a monitoring script checking service uptime, and a coordinated social media bot network would all register as “automated HTTP traffic” in this kind of measurement. Cloudflare’s data tells us volume changed. It does not tell us why, or whose traffic it was.
NetBlocks Adds a Second, More Granular Measurement
NetBlocks, the internet-connectivity monitoring group that frequently tracks disruptions during conflicts, published its own figures covering the same window. Its numbers split the picture by Yandex business unit rather than treating the company as one block. Yandex Cloud traffic fell to approximately 30% of baseline, while Yandex LLC traffic fell to roughly 63%. Those two figures, drawn from the same company during the same strikes, moved by different magnitudes, which is a strong signal that the disruption hit specific infrastructure rather than producing a uniform, company-wide blackout.
That split also undercuts the simplest version of the bot-farm theory. If the strikes had taken out a specific disinformation operation, you would expect a sharp, isolated drop tied to whatever network segment hosted it, not a broad decline spread unevenly across cloud and consumer services. The NetBlocks numbers look more consistent with a company losing compute and connectivity capacity across multiple business lines than with a single bad actor going dark.
| Date (2026) | Metric | Reported Value | Source |
|---|---|---|---|
| Oct 8 | Automated HTTP traffic from Yandex network (vs. 2-week peak) | ~57% | Cloudflare, via The Verge |
| Oct 8-11 | Automated HTTP traffic from Yandex network (vs. 2-week peak) | 0.4% | Cloudflare, via RuntimeWire |
| Oct 11 | Yandex Cloud traffic (vs. baseline) | ~30% | NetBlocks |
| Oct 11 | Yandex LLC traffic (vs. baseline) | ~63% | NetBlocks |
| Oct 8-11 | Strike locations | Sasovo, Kaluga, Vladimir | Multiple outlets |
Why “Russian Bots Went Dark” Is Getting Ahead of the Evidence
The leap from “automated traffic fell” to “Russian disinformation bots were knocked offline” requires several assumptions that none of the available data supports. First, it assumes the automated traffic in question was disinformation-related rather than search crawling, API polling, ad verification, or any of the dozens of legitimate automated functions a company the size of Yandex runs continuously. Second, it assumes the traffic originated from infrastructure specifically dedicated to influence operations, as opposed to shared infrastructure that happened to lose power or connectivity. Third, it assumes the drop was caused by the drone strikes rather than coinciding with them, a distinction that matters a great deal in a region where internet infrastructure sees frequent, unrelated disruptions.
None of this means the bot-farm theory is false. It means nobody has shown it is true. Yahoo News reported that the strikes disrupted more than 80 Russian services, a figure that appears across secondary coverage but has not been independently confirmed by Yandex, Cloudflare, or a named government source. Figures like this tend to get repeated until they calcify into fact, and 80-plus services is a dramatic enough number that it is already doing exactly that online.
What “Automated HTTP Traffic” Actually Covers
It is worth spending a moment on what Cloudflare and NetBlocks are actually counting, because the term “bot traffic” carries a specific cultural meaning that the underlying metric does not guarantee. In network monitoring, automated traffic is any request that doesn’t carry the behavioral fingerprints of a human browsing session, things like consistent click intervals, mouse movement signals, or session persistence patterns that vary the way a person’s would. That bucket includes search engine crawlers, price-comparison scrapers, uptime monitors, API integrations between services, ad-fraud bots, social media automation accounts, and yes, state-linked influence operation accounts.
Yandex runs one of Russia’s largest search engines, meaning a huge share of its own automated traffic is almost certainly its own crawlers indexing the web, plus the API traffic that powers Yandex Cloud customers’ applications. A data center outage would hit all of that simultaneously. Separating “disinformation bot” traffic out of that mix from the outside, using only aggregate network-level measurements, is not something the publicly available data allows anyone to do with confidence.
The Services Reportedly Knocked Offline
Beyond the traffic metrics, the practical story is that Yandex users in multiple Russian cities experienced real service disruption. Yandex Go reportedly went down across seven cities following the strikes, with ride-hailing and payment functions affected. A separate strike on the Vladimir facility was reported with no injuries, and the Vladimir hit followed closely on the heels of an earlier attack described as the third strike on Yandex infrastructure in four days. Separately, reporting indicated Yandex lost access to a portion of its AI computing hardware amid the same campaign.
Those service-level disruptions are easier to verify than the bot-traffic theory because they describe concrete, observable outcomes: an app not loading, a payment not processing, a ride not getting booked. The Sasovo facility’s reported role as host to two supercomputers adds a computing-capacity angle to the story that is separate from, and arguably more consequential than, whatever happened to aggregate bot metrics. Losing supercomputing capacity has direct implications for any AI or large-scale data processing workloads Yandex runs for itself or its cloud customers, regardless of what kind of traffic those systems were serving.
Historical Context: Ukraine’s Drone Campaign Against Digital Infrastructure
Strikes on Russian data centers and cloud infrastructure are not new in 2026, but the frequency has picked up. Three confirmed strikes against a single company’s data centers inside four days represents an escalation in targeting precision and tempo compared to earlier, more sporadic campaigns against Russian digital infrastructure. Ukraine has previously targeted energy infrastructure, refineries, and military-adjacent logistics with drones; data centers represent a newer category of target that sits at the intersection of civilian and dual-use infrastructure, since cloud computing capacity in Russia increasingly underpins both commercial services and state-linked technology projects.
The timing also lands against a backdrop of broader Western pressure on Russian technology and financial infrastructure. The European Union’s addition of 1,646 new sanctions listings against Russia this year reflects a parallel track of economic pressure running alongside direct military action against infrastructure. Whether the Yandex strikes were coordinated with that broader pressure campaign or were an independent military target of opportunity is not addressed in any of the available reporting.
Market and Infrastructure Impact
For a company the size of Yandex, three data center strikes in four days represent a serious operational problem independent of the bot-traffic debate. Yandex Cloud customers running production workloads on affected infrastructure would have experienced real downtime, and any enterprise customer relying on Yandex for mission-critical services now has a fresh data point on geographic concentration risk. Cloud providers operating inside active conflict zones face a different risk calculus than providers in stable regions, and Yandex’s position as both a major Russian cloud provider and a company headquartered partly outside Russia (its parent entity restructured internationally in recent years) puts it in an unusual spot: commercially global in ambition, physically rooted in a war zone for a meaningful share of its compute capacity.
That dynamic has implications beyond Russia. Any enterprise anywhere that treats “data center resilience” as a checkbox rather than a geographic diversification strategy is watching a live case study of what concentrated risk looks like when physical infrastructure becomes a wartime target. Cloud architects elsewhere have spent the past decade designing for hardware failure, natural disaster, and human error. Designing for kinetic military strikes against your own data centers is a scenario that most disaster-recovery playbooks, outside of specific defense and government contractors, simply never modeled.
How This Compares to Other Cloud Disruption Events
Major cloud outages tend to fall into a few recognizable categories: software misconfiguration (the type behind most AWS and Azure incidents), hardware failure, natural disaster, and increasingly, cyberattack. Physical military strikes against data center infrastructure sit in a category almost entirely separate from how Western cloud providers plan for resilience, because none of the hyperscalers operate primary infrastructure inside an active war zone. The table below places the Yandex strikes alongside other notable cloud and infrastructure disruption types for comparison.
| Disruption Type | Example | Primary Cause | Typical Recovery Window |
|---|---|---|---|
| Kinetic strike on data center | Yandex, Sasovo/Kaluga/Vladimir (Oct 2026) | Drone strikes | Days to weeks, hardware-dependent |
| Software misconfiguration | Major hyperscaler regional outages (recurring) | Config/deployment error | Hours |
| DDoS attack | Large-scale volumetric attacks tracked by Cloudflare/Akamai | Malicious traffic flood | Minutes to hours |
| Natural disaster | Regional flooding/storm-related outages | Environmental | Days to weeks |
| Ransomware/cyberattack | Various enterprise cloud tenants | Malicious intrusion | Days to months |
The recovery window for kinetic strikes is the least predictable of the group, since it depends on whether physical hardware, cooling systems, or power infrastructure were destroyed outright versus merely disconnected. The reported loss of two supercomputers at Sasovo suggests at least some of the Yandex damage falls on the slower end of that recovery curve, since replacing specialized computing hardware takes considerably longer than patching a software configuration or rerouting traffic around a flooded facility.
Separating Confirmed Facts From Unverified Claims
Given how much speculation has attached itself to this story in the hours since it broke, it is worth laying out plainly what reporting has actually established versus what remains an open question. The table below separates the two categories based on currently available sourcing.
| Claim | Status | Notes |
|---|---|---|
| Drone strikes hit Yandex facilities in Sasovo, Kaluga, and Vladimir, Oct 8-11, 2026 | Reported by multiple outlets | Consistent across independent reports |
| Automated HTTP traffic from Yandex network fell to 57%, then 0.4%, of 2-week peak | Reported, sourced to Cloudflare data | Measures traffic volume, not traffic intent |
| Yandex Cloud and Yandex LLC traffic fell by different amounts (30% vs 63% of baseline) | Reported, sourced to NetBlocks | Suggests uneven impact across business units |
| Sasovo facility housed two supercomputers | Reported | Cited in coverage of the strikes |
| Traffic drop represents Russian disinformation bots going offline | Unconfirmed | No operator identity or traffic content has been established |
| More than 80 Russian services were disrupted | Unconfirmed figure | Appears in secondary reporting, not independently verified |
| Named officials from Yandex, Cloudflare, NetBlocks, Ukraine, or Russia have commented on record | No verified on-record quotes found | Claims circulating online are not attributed to named sources |
Why the Narrative Spread So Fast Anyway
The “drones accidentally killed a bot farm” framing has an obvious appeal: it turns a military strike into a neat morality story with a side benefit, and it fits an existing prior that a lot of people already hold about Russian state-linked influence operations running through infrastructure like Yandex’s. But the actual data, a network-level traffic measurement with no attribution layer, simply cannot support that level of specificity. This is a pattern that shows up repeatedly in conflict-adjacent tech reporting: a real, verifiable technical data point gets paired with a satisfying but unverified causal story, and the pairing spreads faster than either piece would on its own.
None of this is to say the traffic drop is meaningless. A 99%-plus collapse in automated traffic from a major network is a significant technical event regardless of what was generating that traffic. It is simply a different, narrower claim than “Russian bots went dark,” and treating the two as interchangeable is where this story runs ahead of its evidence.
What Happens Next for Yandex’s Infrastructure
A few things are reasonably predictable from here, even without new confirmed facts. First, expect Yandex to say little publicly beyond standard service-status acknowledgments, consistent with how Russian technology companies have handled similar incidents throughout the conflict. Second, expect independent monitoring groups like NetBlocks and network measurement firms like Cloudflare to keep publishing updated traffic figures as Yandex’s network either recovers or continues to degrade, since this kind of passive measurement does not require Yandex’s cooperation. Third, expect continued strikes on similar infrastructure if the current campaign tempo holds, given that three hits in four days suggests this was not a one-off target.
Fourth, expect the bot-farm narrative to persist online regardless of whether it gets confirmed or debunked, because corrections rarely travel as far as the original claim. And fifth, expect this episode to get cited in future discussions about data center resilience and geographic risk concentration, likely by cloud architects and enterprise risk teams well outside the Russia-Ukraine context, since the underlying lesson, that physical infrastructure concentration is a real tail risk, applies everywhere, not just to companies operating inside a conflict zone.
The Bigger Picture for Cloud Infrastructure Resilience
Strip away the bot-farm speculation and what remains is a straightforward infrastructure story: a major cloud and internet services provider lost access to physical facilities, including specialized computing hardware, across three sites in under a week. That is the part of this story with the clearest evidence trail, and it is arguably the more consequential one for anyone running production workloads on contested infrastructure. Enterprises evaluating cloud providers with any physical footprint in active conflict zones now have a concrete, documented case of what multi-site, multi-day disruption looks like in practice, including the uneven way it can hit different business units within the same company.
The bot-traffic angle will likely keep generating headlines because it is the more viral, more shareable version of the story. But the infrastructure resilience angle, three strikes, two supercomputers, uneven traffic drops across business units, is the version with an actual evidentiary record behind it, and it is the one worth paying attention to if the goal is understanding what happened rather than what people want to believe happened.
Frequently Asked Questions
Did Ukrainian drone strikes really hit Yandex data centers?
Multiple outlets reported strikes on Yandex facilities in Sasovo, Kaluga, and Vladimir between October 8 and October 11, 2026. The pattern of three strikes on the same company’s infrastructure within four days has been consistently reported across independent sources.
Is it true that Russian bot traffic dropped after the strikes?
Automated HTTP traffic attributed to the Yandex network did fall sharply, from roughly 57% of its two-week peak down to 0.4%, according to Cloudflare data. Whether that traffic specifically represented disinformation bots, as opposed to crawlers, APIs, or other automated services, has not been established.
What is the difference between the Cloudflare and NetBlocks figures?
Cloudflare measured aggregate automated HTTP traffic from the whole Yandex network. NetBlocks broke the measurement down by business unit, finding Yandex Cloud traffic fell to about 30% of baseline while Yandex LLC traffic fell to about 63%, suggesting the impact varied across different parts of the company.
Were more than 80 Russian services actually disrupted?
That figure appears in secondary reporting but has not been independently confirmed by Yandex or by the organizations that produced the underlying traffic data. It should be treated as unverified until a primary source confirms it.
What was at the Sasovo facility?
Reports indicate the Sasovo site housed two supercomputers. That detail suggests the strike may have affected high-performance computing capacity, separate from whatever happened to broader network traffic patterns.
Has Yandex or Cloudflare officially commented on the cause of the traffic drop?
No verified on-record quotes from Yandex, Cloudflare, NetBlocks, or Ukrainian or Russian officials addressing the cause of the traffic drop were identified in available reporting as of this writing.
Why does this matter for cloud computing outside of Russia?
The episode is a live example of how physical infrastructure concentration becomes a tail risk when facilities sit inside an active conflict zone. It is a useful data point for enterprise risk teams thinking about geographic diversification, even if their own infrastructure has nothing to do with Russia or Ukraine.
Could the traffic drop have been caused by something other than the drone strikes?
The timeline reported by multiple outlets places the traffic decline after each strike, which is suggestive but not the same as a confirmed causal link. Internet infrastructure in the region has experienced other disruptions during the broader conflict, so a direct causal claim would need more technical detail than has been publicly released.
Related Coverage
- Build a Game Streaming Service: AWS Setup in 13 Steps [2026]
- Vivox vs Agora vs Azure ACS: 25x Voice-Chat Gap [2026]
- AWS Wavelength vs Azure Edge vs GDC Edge: 10ms Gap [2026]
- Terraform AWS Game Server Fleet: Deploy in 13 Steps [2026]
- AWS GameLift Local Zones Setup: 9 Zones in 13 Steps [2026]
