Drone strikes took out three Yandex data centres in four days. The 'Russian bots went dark' chart says something else.

Drone strikes took out three Yandex data centres in four days. The "Russian bots went dark" chart says something else.

The story that travelled fastest this week was the satisfying one. Ukraine hit Russia's tech backbone, Cloudflare's bot-traffic chart for Yandex's network fell off a cliff, and the headline wrote itself: Russian disinformation bot traffic "nearly eliminated overnight."

The chart does not say that. Cloudflare's numbers count automated HTTP requests coming from Yandex's network, and Yandex runs one of the world's largest search engines, whose crawlers are almost constantly fetching pages. When that network loses most of its capacity, its automated request volume collapses. That is a measurement of infrastructure, not intent. What the same chart cannot show is whether any of the traffic belonged to an influence operation, or who was running it.

The story underneath is the one worth an enterprise's attention: a cloud provider lost one site, then a second, then a third in four days, and its customers were told to start their disaster recovery plans.

Three sites, four days

Yandex's own statement, published on 9 October, is the clearest account of the sequence. "On the night of October 7th to 8th, the Yandex data center in Sasovo was seriously damaged in a drone attack. It has been completely shut down. This morning, another of our data centers, in Kaluga, was attacked. Part of its infrastructure is out of service." The company said no employees were hurt and that it was still assessing the damage. "For now, it is very difficult to say when the equipment at the data centers will be back up and running."

Sasovo matters most operationally. It opened in 2014 on the site of the former Sasta machine-tool plant, roughly 300 kilometres from Moscow, and holds tens of thousands of servers. It also houses two of Yandex's three AI supercomputers, Chervonenkis and Lyapunov, which Reuters reports were built with Nvidia A100 accelerators to train the company's own models. Yandex has declined to say whether they were damaged.

Kaluga was the bigger campus on paper. Yandex designed it as its largest, with 63 megawatts of capacity and room for more than 3,800 racks across 130,000 square metres, according to The Insider. The first phase was commissioned in December 2023 and connected to the grid at 49 megawatts in October 2024.

The third strike landed on Vladimir on 11 October. Yandex said the data centre there "has been completely shut down as a result of a drone attack," and that no one was injured. Vladimir hosts the ru-central1-a availability zone, and a 40-megawatt building with room for 2,800 racks opened next to it in March 2026. The regional governor, Alexander Avdeyev, confirmed a strike on an infrastructure facility and a fire. Kyiv Post reported that crews had restored heat, water and roughly 80 percent of power to affected areas by the following morning.

Ukraine's government has not formally claimed all three strikes. President Zelensky said on 8 October that Russia "has been hitting and continues to hit our data centres" and that "we always respond in mirror-like fashion," without naming Yandex. Fire Point, the Ukrainian company that builds the FP-1 long-range drone, said on Telegram that its weapon was used against the Kaluga site. Russia's defence ministry said its air defences intercepted 479 Ukrainian drones across 16 regions overnight into 11 October, a figure that comes from the ministry and has not been independently verified.

What the outages actually cost

Yandex Cloud's status page listed at least 84 services offline after the third strike, and reporting drawn from monitoring channels put more than 80 Yandex platforms out of action. The list is a fair picture of what a modern cloud provider actually is: compute, object storage, managed Kubernetes, PostgreSQL and ClickHouse databases, the YandexGPT API, SpeechKit, Vision OCR. On the consumer side, Alice, Yandex Music, Telemost and Smart Home all broke. Failures rippled out to third-party banking apps and retail chains including Magnit and Fix Price. The service counts come from reporting rather than a company-confirmed total, so treat them as a floor rather than a figure.

NetBlocks, which measures network availability, put traffic on Yandex's network at about 30 percent of normal for Yandex Cloud and 63 percent for Yandex LLC, the operating company. Yandex told cloud customers the platform was running in emergency mode and advised them to activate their disaster recovery plans, and pointed them at three Russian competitors, Selectel, K2Cloud and VK Cloud, to move workloads and data off its own estate. The company also removed its data centres in four regions from its own mapping service, with satellite views of the sites blurred, as the independent outlet Verstka found. Two Russian outlets ran the company's statement with the phrase "as a result of a drone attack" replaced by "an incident occurred."

Yandex shares fell on the Moscow Exchange as the damage accumulated, with reporting citing a decline of nearly 4 percent after the second strike.

The chart that says something else

Tom's Hardware reported on 11 October, under a headline saying Yandex's "disinformation bot traffic" had been "nearly eliminated overnight," that bot traffic from the Yandex network had fallen to 0.4 percent of the maximum number of HTTP requests Cloudflare recorded from it over the preceding two weeks. It had initially dropped to about 57 percent on 8 October, the day of the Sasovo strike.

The Verge published the correction the next morning. A thread by antibot4navalny, which has tracked state-sponsored social media campaigns and troll farms, explains that the chart is about automated web crawlers run by Yandex fetching pages across the web. It is not about "bots" posting on social media, and Russian bot and crawler traffic overall is running at about normal levels.

There is a second, subtler trap in the same number. Cloudflare Radar's 0.4 percent is the human share of traffic from that network over the 5 to 11 October window, which is the same thing as saying 99.6 percent of it was automated. Tom's Hardware's 0.4 percent is request volume against a two-week maximum. Two different measurements, one identical figure, circulating in the same conversation.

What the Radar data can support is narrow. In the hours after the third strike, automated requests from AS13238 sat at 0.3 to 0.5 percent of the chart's recent maximum, against roughly 87 to 88 percent at the same hour a week earlier. But the chart cannot separate fewer bots from fewer working servers, because with much of the operator's capacity physically offline both would fall together. The comparison line for the week before the strikes already shows a deep dip and a recovery, which is the kind of thing a single screenshot of a chart tends to leave out. The Verge's closing line was the honest one: it asked readers whether they had noticed any actual difference in the posts and comments they see.

The second cloud provider to lose sites this year

The Register drew the comparison that matters for anyone buying infrastructure: if Yandex has to write off Sasovo, it becomes the second cloud provider this year to lose facilities to drone attack, after AWS concluded that its Bahrain region could not be recovered following an Iranian strike.

DMC covered that one in September, when AWS's health dashboard confirmed that resources and data hosted exclusively in the Bahrain region, and in one UAE availability zone, were unrecoverable, with damage that "exceeded what our regional and multi-AZ services are designed to withstand."

Here is the uncomfortable part for anyone relying on the standard resilience checklist. Yandex's customers were sold the same architecture everyone else is: multiple availability zones, failover between them, capacity spread across sites. It did not survive contact with three strikes in four days. Two of the three hit sites were fully down and one partly, and the recovery route normally available to a Western customer, moving to a provider in a different jurisdiction, is largely closed to Russian businesses. Sanctions keep them out of clouds across the border, the domestic operator pool is small, and Federal Law 242-FZ requires Russian citizens' personal data to be held primarily in databases inside the country. Redundancy you cannot relocate is a failover plan, not a disaster plan.

One further constraint is specific to this story. US and European export controls bar the sale of advanced AI accelerators to Russia. If the A100-based supercomputers at Sasovo were destroyed rather than merely offline, replacing that training capacity is a materially harder problem for Yandex than for a competitor that can buy more GPUs. The company has not said which it is.

What to take from it

Two lessons, and they are the same lesson wearing different clothes.

A whole-site outage is now a planning input rather than a line in a risk register. Yandex is an extreme case, but the question it forces is not exotic: if this region, this provider, or this country is not available tomorrow, what keeps running, from where, and how long does recovery take. Multi-zone architecture answers a high-availability question. It does not answer a rebuild question, and the difference between the two is the difference between a bad morning and an unrecoverable one.

The second is about knowing what your own numbers mean. A chart can be entirely accurate about the thing it counts and still be read as a claim about something else, which is how a request count from a search engine's crawlers became proof that a disinformation operation had collapsed. The same discipline applies to any dashboard an operations team trusts: what is this counting, and what would have to change for it to move.

At DMC we work on that layer for companies running production infrastructure: mapping workloads to the places they physically live, designing a recovery path that does not depend on the same site, the same provider or the same jurisdiction, and checking that the telemetry on the wall measures what the team believes it measures. If you are reviewing whether your resilience plan survives its worst case rather than its most convenient one, let's talk.