Russian IT giant Yandex suffered damage at three data centers in a series of drone attacks between October 8 and 11, 2026. The facilities in Sasovo and Vladimir were shut down completely, and some equipment in Kaluga also became unusable. Around the same time, bot traffic originating from Yandex's network dropped sharply. However, Cloudflare's public data shows traffic partially recovered in the latter part of October 11. There is no basis for interpreting the drop in traffic as evidence that Russian disinformation operations have been wiped out. What the official announcements do make clear is a shortage of the computing resources needed to restore the affected cloud services, along with serious knock-on effects that reached even corporate document workflows.
Successive attacks on three sites put Yandex Cloud into emergency operation
According to a statement Yandex released on October 9, the first damage occurred overnight between October 7 and 8. The data center in Sasovo, Ryazan Oblast, was attacked, suffered severe damage, and stopped operating entirely.
On the morning of the 9th, the data center in Kaluga was also attacked, and part of its infrastructure went down. No employees were injured at either facility, but at the time it was unclear when the equipment could be restored.
On the 11th, the facility in Vladimir was also damaged.
The official Telegram channel "Yandex Cloud Alerts" announced that a drone attack had damaged equipment at the data center there and brought it to a complete halt. No casualties were reported in this case either.
Yandex explained that service delivery using the remaining facilities and computing resources was unstable, and it moved its cloud platform to an emergency operating mode. It urged customers to execute disaster recovery plans to restore their services in other environments.
That said, the shutdown of multiple data centers did not make all of Yandex's services unavailable.
An announcement on the recovery status on the 11th said the cloud management console and API were available and some computing resources could still be used.
For databases, switchover to other environments was under way, but some were still limited to read-only mode and others remained unavailable.
In other words, the impact of the outage varied by service, and even within the same service, the operations that could be performed differed.
The number of halted facilities alone does not determine which operations are affected by data center damage. How difficult recovery is also depends on where users had placed their data and workloads, and on what can be run on substitute facilities.
Does the sharp drop in "bot traffic" mean disinformation output stopped?
What Cloudflare Radar showed falling sharply was HTTP requests from AS13238, a network operated by Yandex, that were estimated to be automated traffic.
An AS (autonomous system) is a unit of network operated under a common administrative policy.
This data therefore shows neither the volume of internet traffic across Russia nor the number of messages posted on any particular social network.
According to Cloudflare's explanation of its bot classification, traffic with a bot score of 1 to 29 is classified as likely automated, while a score of 30 or higher is classified as likely human.
However, this mechanism assesses only the likelihood that traffic was automatically generated. It does not examine whether the content is political propaganda or who funds and operates it.
In addition, Cloudflare Radar uses data on traffic that passed through Cloudflare's network. It is not a statistic covering all traffic on the internet, and that is worth keeping in mind.
Furthermore, AS13238 is also used for legitimate web crawling by Yandex's search engine.
Yandex's official bot identification guide lists AS13238 as a network used by its bots and also explains the role of YandexBot, which collects web pages.
For a search engine to update its results, its bots must continually crawl external websites and gather information.
If such legitimate crawling stops, it also appears as a drop in bot traffic on Cloudflare's graph.
Of course, this data alone cannot tell us how much of the decline in traffic was search engine crawling.
What matters is that there is no basis for treating all automated traffic from a network that also serves legitimate purposes as disinformation activity.
At the same time, this observation does not deny the existence of influence operations themselves.
Identifying the content of the traffic or who operates it requires evidence other than traffic trends.
Traffic fell to nearly zero, then partly recovered later on the 11th
Cloudflare Radar's Data Explorer lets you view the trend over a given period for bot traffic originating from AS13238.
Comparing against the maximum value in the same observation period set to 100, AS13238's bot traffic plunged to about 0.29 at 03:00 on October 11 but had recovered to about 11.03 by 22:00 the same day.
The table below picks out key hours on the 11th from data covering 00:00 on October 1 through 23:00 on October 11.
All times are in Coordinated Universal Time (UTC), not Moscow local time.
| Time on October 11 (UTC) | Published normalized value | Traffic with the period maximum set to 100 |
|---|---|---|
| 03:00 | 0.002942 | ~0.29 |
| 15:00 | 0.192477 | ~19.25 |
| 22:00 | 0.11028 | ~11.03 |
The Data Explorer response uses a normalization method called "MIN0_MAX."
According to Cloudflare's definition, this method sets the maximum value in the period to 1 and expresses each value as a relative ratio.
In the table above, the published values are multiplied by 100 and rounded to two decimal places.
The baseline is the maximum hourly traffic volume in the specified period. It does not indicate the total number of bots in Russia, nor the share of bots in overall traffic including human traffic.
Nor can the actual number of HTTP requests be determined from this data.
It is certain that traffic at 03:00 on the 11th fell to an extremely low level.
However, by 15:00 it had recovered to about 19.25% of the period maximum, and at 22:00 it still held at about 11.03%. Although it dipped again in between, traffic was not stuck near zero.
Treating a temporary plunge as a prolonged complete outage would cause these changes to be overlooked.
Also, while the timing of the attacks on the data centers overlaps with the traffic plunge, this graph alone cannot identify how much the shutdown of each facility affected traffic volume.
It is also unclear whether the recovered traffic reflects restoration of the original facilities or the shifting of processing to other facilities.
A recovery in bot traffic is a separate matter from a recovery in the processing capacity of the damaged data centers.
Spreading data centers out doesn't help if the recovery site lacks spare capacity
Yandex Cloud's explanation of availability zones describes how cloud resources such as virtual machines and disks are tied to specific availability zones.
An availability zone is a unit that divides the facilities providing cloud services by the scope of failure impact.
By using different zones, the effect on other zones can be limited even if one zone's equipment or software fails.
Distributing an application across multiple zones raises the likelihood that service can continue even if some equipment fails.
However, the mere existence of other sites does not guarantee they can take over all the processing of a halted facility.
The destination also needs sufficient computing resources, and it is essential that the application can access the data it uses.
Even if new virtual machines can be launched, the original operations cannot resume unless the necessary disks and backup data are available.
Yandex's documentation on operating virtual machine groups during a zone failure gives a concrete example of securing such spare capacity.
It says that when running an application that needs 9 virtual machines across two zones, you prepare 9 in each zone, for a total of 18.
With this configuration, even if one zone stops completely, the 9 machines remaining in the other can maintain the required processing capacity.
By contrast, simply spreading a total of 9 virtual machines across two zones would not leave the required 9 if one went down.
Of course, this is a design example presented by Yandex and does not show how much reserve capacity the company actually had when this outage occurred.
Still, it shows that distributing facilities across multiple locations and securing the processing capacity needed during a failure are separate challenges.
In an ordinary equipment failure, distributing across multiple zones may limit the impact. But if multiple data centers suffer physical damage in succession, the available computing resources themselves shrink.
The official announcements this time also contain hints of a resource shortage at the recovery destination.
On the 10th, Yandex said it would manage compute and disk quotas entirely manually. On the 11th, it announced that it had stopped issuing new compute resource quotas.
The fact that it advised users to recover on other cloud platforms also suggests that simply adding the needed resources within the same platform could not meet demand.
A data center is a large physical facility that includes not only servers but also power equipment, networking, and storage.
Even if a destination for processing can be specified in software, actual operations cannot resume unless the necessary equipment and data are in place there.
Cloud outage spreads to electronic filing and shipping documents
The damage to the data centers has affected the operations of companies that use the cloud.
In an announcement as of 08:00 on October 11, Russian business services company Astral said it was experiencing outages in services for electronic filing, electronic document exchange, and electronic shipping documents.
According to the company, multiple services were affected after Yandex's data center in Vladimir was damaged in a new drone attack.
It advised users who encounter errors when sending documents or applying electronic signatures to retry after some time.
Astral also prepared documents for regulators to explain that filings could not be submitted by the deadline because of the technical outage.
This is an example of a cloud outage affecting not just the ability to open websites but also companies' filing work and transport-related procedures.
However, this announcement describes an outage in Astral's services and does not mean logistics across all of Russia has stopped.
Also, a recovery in traffic alone is not enough to judge whether services have been restored.
Being able to access the management console, read stored data, update data, and complete the creation, signing, and sending of documents are each different things.
For example, even if stored documents become viewable, disruption to operations continues if new shipping documents cannot be created, electronically signed, or sent.
What the damage to Yandex highlights is the reality that even a cloud provider with multiple data centers can find it hard to keep services running when physical attacks come in succession.
Even if data survives intact, operations cannot resume unless the computing resources to process it can be secured in another environment.
Cloudflare's traffic data offers a clue to the impact the outage had on the network. But it alone cannot determine the full extent of the damage, the state of recovery, or, still less, the effect on disinformation activity.
What matters is not just whether traffic has recovered, but whether users are back to reading and writing data and completing the operations they need from start to finish.
This case, in which damage spread across multiple sites, shows that when thinking about cloud resilience, it is important to secure processing capacity and data access at the recovery destination in addition to distributing facilities.