Yandex Outage: Bot Traffic Falls to 0.4% [2026]

A string of Ukrainian drone strikes on Yandex data centers this month produced a headline too tidy to be true: automated traffic from Russia’s largest tech company collapsed to 0.4% of its two-week peak, and social media immediately read that as proof that a wave of Russian disinformation bots had been knocked offline. On October 12, 2026, The Verge reported that the claim does not hold up to scrutiny. The underlying data, pulled from Cloudflare Radar, measures automated HTTP requests originating from Yandex’s network. It says nothing about who was running those requests, why, or whether they had anything to do with disinformation at all.

The distinction matters because the Yandex outage is a real, physically verifiable event with real consequences for cloud infrastructure, e-commerce, and tens of millions of daily users across Russia. Three separate drone strikes between October 8 and October 11, 2026 hit Yandex facilities in Sasovo, Kaluga, and Vladimir, according to multiple outlets tracking the story. What followed is a case study in how infrastructure damage, network monitoring data, and online narrative can diverge within hours of a breaking story, and why engineers and journalists alike need to be careful about conflating “traffic dropped” with “bots were destroyed.”

Google · Preferred Sources

Don't miss new tech stories on Google

Add TrendinTech once in the Google app and our stories appear in your news suggestions.

Add Now

What Happened: Three Drone Strikes in Four Days

The timeline, as reconstructed from reporting by Yahoo News and other outlets, begins on October 8, 2026, when a drone strike hit a Yandex-linked data center in Sasovo. A second facility in Kaluga was reportedly hit in the days that followed, and on October 11, 2026, Yandex confirmed that its data center in Vladimir had been forced offline after a direct drone attack. That third strike is the one that pushed the story into mainstream tech coverage, because it coincided with the sharpest reported drop in network activity.

Yandex Cloud, the company’s public cloud division and the Russian equivalent of AWS or Azure in scale and ambition, reported that at least 84 services went offline in the aftermath. That list reportedly included consumer-facing products like Yandex Go (ride-hailing and delivery), Yandex Pay, Yandex Music, the company’s voice assistant, and various delivery services, alongside backend Yandex Cloud infrastructure that other businesses depend on. For a company often described as “Russia’s Google,” a disruption of that scale is not a minor technical hiccup. It is closer to what would happen if a major US hyperscaler lost three regional data centers inside one work week.

The Cloudflare Numbers Behind the Bot-Traffic Claim

The number driving the viral narrative comes from Cloudflare Radar, which tracks automated HTTP traffic patterns across autonomous systems, including the one assigned to Yandex’s network. According to data cited by RuntimeWire, automated traffic from the Yandex network fell to roughly 57% of its recent baseline after the October 8 Sasovo strike, then continued sliding until it bottomed out at just 0.4% of its maximum two-week level following the third strike on October 11.

That is a dramatic number by any measure, and it is the kind of statistic that travels fast online precisely because it is easy to repeat and hard to verify in real time. The mistake, as outlets digging deeper into the story have pointed out, is treating “automated HTTP traffic” as a synonym for “disinformation bots.” Cloudflare’s measurement is a network-level signal. It counts requests that look automated rather than human-driven. It does not, and cannot, tell you whether those requests came from search-engine crawlers, internal Yandex services, legitimate third-party integrations, or coordinated influence accounts. Collapsing all of that into “Russian bots” is a narrative leap the data does not support.

NetBlocks vs Cloudflare: Diverging Measurements

Adding to the confusion, a second independent monitor tells a less dramatic story. NetBlocks, the internet-observatory group that tracks connectivity disruptions worldwide, reported traffic falling to about 30% for Yandex Cloud and roughly 63% for Yandex LLC, the parent corporate network. Those figures are serious, consistent with real infrastructure damage, but they are nowhere near the 0.4% figure that Cloudflare’s automated-traffic metric produced.

The gap between those two readings is itself the more interesting data point for anyone trying to understand what is actually happening inside Yandex’s network right now. Cloudflare and NetBlocks are not measuring identical things. Cloudflare Radar’s bot-traffic metric is specifically tuned to flag non-human request patterns, while NetBlocks tracks broader connectivity and reachability signals across the autonomous system. A sharp drop in one and a more moderate drop in the other is consistent with a scenario where automated, possibly bot-like traffic was disproportionately affected, which could just as easily mean that automated internal services, scheduled jobs, or crawler traffic got knocked out first, rather than confirming any specific disinformation infrastructure was destroyed.

Monitoring Service	Date Reported	Metric Tracked	Reported Level
Cloudflare Radar	Oct 8, 2026	Automated HTTP traffic from Yandex network	~57% of 2-week peak
Cloudflare Radar	Oct 11, 2026 (after 3rd strike)	Automated HTTP traffic from Yandex network	0.4% of 2-week peak
NetBlocks	Oct 11, 2026	Yandex Cloud connectivity	~30%
NetBlocks	Oct 11, 2026	Yandex LLC connectivity	~63%

Why “Russian Bots” Is the Wrong Headline

Part of why the bot-traffic framing spread so quickly is that it fits a story people already wanted to believe: Ukrainian drones taking out not just servers, but the machinery of Russian information warfare, in one tidy strike. It is a satisfying narrative. It is also, based on the available evidence, unsupported. As reporting on the story has noted, the drop in automated traffic coincides with physical infrastructure going offline, which is exactly what you would expect from a successful strike on a data center, independent of whatever that data center was running. A data center that goes dark stops serving everything hosted on it: bots, legitimate crawlers, consumer apps, and backend services alike.

Put another way, there is a difference between “we destroyed the servers running disinformation bots” and “we destroyed servers, and some of what they were running happened to generate automated traffic.” The first is a targeted counter-disinformation claim. The second is simply a description of what happens when you knock out a data center. Nothing in the Cloudflare or NetBlocks data, as currently published, distinguishes between those two scenarios. That is the core of the correction that outlets have issued around this story: the traffic numbers are real, but the interpretation attached to them outran the evidence within hours of the story breaking.

Yandex Cloud’s 84 Services and What Went Dark

Stripping out the disinformation angle, the infrastructure story on its own is significant. Yandex Cloud reporting at least 84 affected services is a scale of outage that would make front-page news for any major Western cloud provider. The affected list spans Yandex Go, the company’s ride-hailing and food-delivery platform; Yandex Pay, its payments product; Yandex Music; the company’s voice-assistant product; and a range of delivery services that Russian consumers rely on daily. Also affected, according to the reporting, was Yandex Cloud itself, the enterprise and developer-facing infrastructure layer that other Russian businesses build on top of.

That last point is the one with the longest tail. Consumer apps going offline for a few hours is bad publicity. A cloud infrastructure provider losing three data centers in four days raises much harder questions for every business that has architected its systems around Yandex Cloud as a single point of dependency. Multi-region redundancy inside Russia’s borders is a different engineering problem than multi-region redundancy across US, European, or Asian availability zones, and this incident is likely to push Russian enterprises to confront that gap directly.

Inside the Three Facilities: Sasovo, Kaluga, Vladimir

Little independently verified detail has emerged about the internal capacity or specific workloads of the Sasovo, Kaluga, and Vladimir facilities, beyond their role in Yandex’s broader infrastructure footprint. Yandex itself confirmed the Vladimir strike and the resulting outage in its own public communications around October 11, according to multiple outlets tracking the story, which is a notable level of transparency for a company operating inside a wartime information environment where infrastructure outages are often downplayed or denied outright.

That willingness to confirm the Vladimir outage, even as the broader bot-traffic narrative spiraled out of the company’s control, suggests Yandex judged that denying a physically obvious, multi-service outage was a worse strategy than acknowledging it while staying silent on causes and attribution specifics beyond the fact of drone strikes already being reported elsewhere.

Date	Facility	Reported Status
Oct 8, 2026	Sasovo data center	Drone strike reported; automated traffic fell to ~57% of baseline
Between Oct 8-11, 2026	Kaluga data center	Reported among the three strikes affecting Yandex infrastructure
Oct 11, 2026	Vladimir data center	Forced offline after drone attack; Yandex confirmed the outage

Historical Context: Data Centers as Wartime Targets

Targeting data centers and communications infrastructure is not a new tactic in the broader conflict between Russia and Ukraine, but the specific targeting of a civilian-facing cloud and consumer-tech operator at this scale marks an escalation in how digital infrastructure has become a battlefield asset. Over the course of the war, both sides have periodically targeted telecommunications towers, internet exchange points, and now, increasingly, the physical data centers underpinning cloud and consumer platforms. Yandex occupies a unique position in that landscape: it is simultaneously Russia’s dominant search engine, its largest ride-hailing and delivery operator, and a cloud infrastructure provider used by businesses across the country, making it both a civilian service and, in the eyes of those striking it, a piece of state-adjacent digital infrastructure.

That dual identity is precisely why the bot-traffic narrative took hold so easily. Yandex has long faced accusations, documented in various contexts over the years, of having ties to Russian state interests given the company’s scale and the regulatory environment it operates in domestically. Audiences primed to see Yandex as an arm of state messaging were always going to read “Yandex traffic dropped” as “state bots went dark.” The infrastructure reality, three data centers damaged in four days, is dramatic enough on its own without needing an unverified disinformation angle attached to it.

Market Impact: What This Means for Yandex and Russian Tech

For a company of Yandex’s scale, an 84-service outage spanning ride-hailing, payments, music, voice assistant, and core cloud infrastructure represents a direct hit to daily revenue-generating operations, not just a reputational embarrassment. Yandex Go alone processes a meaningful share of Russia’s urban ride-hailing and food-delivery transactions, and payment processing outages through Yandex Pay would have immediately affected merchants relying on that rail for settlement. Every hour those services stayed dark is an hour of lost transaction volume that does not simply get recovered once systems come back online.

The more durable market impact, though, is likely to land on Yandex Cloud’s enterprise customers. Any Russian business running production workloads on Yandex Cloud infrastructure now has a concrete, recent example of multi-region failure risk to point to internally. That is the kind of incident that reshapes procurement conversations for years, not weeks. Expect increased interest in on-premises failover, geographically dispersed backup contracts, and multi-cloud strategies among Yandex Cloud’s enterprise customer base, even though options for diversifying outside Russian-controlled infrastructure remain constrained by sanctions and regulatory pressure.

Competitive Comparison: Yandex Cloud vs Global Hyperscalers on Resilience

It is worth putting Yandex Cloud’s current predicament next to how AWS, Microsoft Azure, and Google Cloud design around physical-site risk, because the contrast illustrates exactly what has gone wrong here. Hyperscalers spread workloads across dozens of availability zones and multiple geographic regions specifically so that the loss of any single facility, whether from a natural disaster, a power failure, or a targeted attack, does not take down customer-facing services at scale. Yandex Cloud, operating primarily within Russian borders and under far more limited options for truly independent redundant sites, does not have that same geographic cushion available to it in the current environment.

That is not a knock on Yandex’s engineering specifically. It is a structural reality of running cloud infrastructure inside a country that is an active target in a drone and missile campaign, where every physical facility, no matter how well distributed on paper, sits inside the same geographic blast radius. Western hyperscalers have never had to design around that threat model at this intensity inside their core markets. Yandex Cloud now effectively has to, in real time, while keeping consumer services like Yandex Go and Yandex Music running for tens of millions of daily users who have no direct stake in the broader conflict.

The Disinformation Measurement Problem

Beyond the Yandex-specific story, this episode is a useful case study in a broader problem: network-traffic telemetry from services like Cloudflare Radar is genuinely valuable for understanding infrastructure health, but it was never designed to answer attribution questions like “whose bots were these” or “what was this automated traffic actually doing.” As the deep dive noted in its coverage, Radar’s chart for the Yandex autonomous system shows a real and measurable drop, but several posts describing that drop as “Russian bot traffic” are making an inferential leap the underlying chart does not support on its own.

This is not a new failure mode in tech journalism or social media discourse. Network telemetry, server logs, and traffic dashboards get treated as if they answer questions about intent and identity, when they are, at best, indirect proxies. A security researcher or network engineer reading the same Cloudflare chart would likely describe it in far more conservative terms: automated request volume from a specific autonomous system dropped sharply, coincident with physical infrastructure damage. Everything beyond that sentence, including who ran the bots, what they were doing, and whether disinformation operations were specifically disrupted, is speculation dressed up as data-backed reporting.

What Cloud and Infrastructure Teams Should Take Away From This

For engineering and infrastructure teams well outside the immediate conflict, the practical lesson is less about geopolitics and more about monitoring hygiene. When a monitoring dashboard shows a dramatic traffic drop, the first question should always be “what changed at the infrastructure layer,” not “what does this traffic drop prove about the traffic’s origin or purpose.” Confusing those two questions, correlation with attribution, is exactly how a straightforward infrastructure outage got dressed up as a disinformation takedown within hours of the first reports.

It is also a reminder that single-metric storytelling is risky. Cloudflare’s 0.4% figure and NetBlocks’ 30%/63% figures are both legitimate measurements, but they diverge enough that neither one alone tells the full story. Teams building their own incident dashboards, or anyone covering outages for an audience, should default to citing multiple independent monitors side by side rather than leaning on whichever single number produces the most dramatic headline.

Predictions: Where This Story Goes Next

Expect Yandex to continue restoring services incrementally over the coming days and weeks rather than all at once, given that three separate facilities were affected rather than one.
Expect continued disagreement between automated-traffic monitors like Cloudflare and connectivity monitors like NetBlocks on the exact scale of the disruption, since they are measuring structurally different signals.
Expect the “Russian bots eliminated” framing to keep circulating on social media even after corrective reporting, since the dramatic version of a story typically outlives its correction online.
Expect Russian enterprises running production workloads on Yandex Cloud to accelerate conversations around backup infrastructure and failover planning following this incident.
Expect further scrutiny of Yandex’s three affected sites (Sasovo, Kaluga, and Vladimir) as outlets continue to update casualty-free infrastructure damage assessments in the days following October 11, 2026.

Separating the Verified From the Viral

What is verified: three drone strikes hit Yandex-linked data centers in Sasovo, Kaluga, and Vladimir between October 8 and October 11, 2026. Yandex confirmed the Vladimir facility went offline after a drone attack. Cloudflare Radar data showed automated HTTP traffic from the Yandex network falling to 0.4% of its two-week peak, following an intermediate drop to roughly 57% after the first strike. NetBlocks independently reported connectivity falling to about 30% for Yandex Cloud and 63% for Yandex LLC. Yandex Cloud reported at least 84 services offline, spanning Yandex Go, Yandex Pay, Yandex Music, the voice assistant, and various delivery platforms.

What is not verified: that the measured traffic represented Russian disinformation bots specifically, and that the outage “blitzed” or eliminated that disinformation infrastructure. The underlying data identifies neither the operators nor the purpose of the automated traffic in question, and a drop in automated requests is just as consistent with general infrastructure disruption as it is with a targeted counter-disinformation outcome. Readers and engineers alike should treat the raw outage numbers as solid ground and the bot-elimination narrative as an inference that the current public data cannot support.

Frequently Asked Questions

What caused the Yandex outage in October 2026?
Three drone strikes hit Yandex-linked data centers in Sasovo, Kaluga, and Vladimir between October 8 and October 11, 2026, according to multiple outlets including The Verge and Yahoo News. Yandex confirmed its Vladimir facility was forced offline after the third strike.

Did the Yandex outage really eliminate Russian bot traffic?
That claim is unverified. Cloudflare Radar data showed automated HTTP traffic from the Yandex network falling to 0.4% of its two-week peak, but that metric measures automated request patterns, not the identity or purpose of whoever generated them. Reporting from The Verge and other outlets has specifically pushed back on the “Russian bots” framing.

How many Yandex services were affected by the outage?
Yandex Cloud reported at least 84 services offline, including Yandex Go, Yandex Pay, Yandex Music, the company’s voice assistant, and several delivery services.

What is the difference between the Cloudflare and NetBlocks numbers?
Cloudflare Radar measures automated HTTP traffic specifically, which fell to 0.4% of its two-week peak. NetBlocks measures broader network connectivity, which it reported falling to about 30% for Yandex Cloud and roughly 63% for Yandex LLC. The two monitors track different signals, which explains why their numbers diverge.

Which Yandex data centers were hit by drone strikes?
Reports name three facilities: Sasovo, Kaluga, and Vladimir. The Vladimir strike on October 11, 2026 is the one Yandex itself publicly confirmed caused an outage at that site.

Is there a confirmed link between the traffic drop and disinformation operations?
No. The available data does not identify who was operating the automated traffic that Cloudflare measured or what that traffic was being used for. A drop in automated requests following physical data center damage is also consistent with ordinary infrastructure disruption unrelated to any specific bot network.

What happens to businesses that rely on Yandex Cloud?
Businesses running production workloads on Yandex Cloud faced direct disruption during the outage window and are likely to reassess redundancy and failover planning, since Yandex Cloud’s current footprint is concentrated within Russian borders and cannot draw on the geographically dispersed availability zones that providers like AWS, Azure, and Google Cloud offer elsewhere in the world.

How did Yandex respond to the outage?
Yandex publicly confirmed the Vladimir facility outage following the drone attack, according to reporting from multiple outlets, though the company has not issued detailed statements addressing the bot-traffic interpretation circulating separately online.

Yandex Outage: Bot Traffic Hits 0.4%, Not Proof [2026]