From October 8 to 11, 2026, Yandex lost three data centers: Sasovo and Vladimir were completely shut down, while Kaluga operated with degradation. Yandex Cloud switched to emergency mode and directly advised clients to activate their own disaster recovery plans. The most interesting events occurred afterward. Cloudflare analyzed what happened to the bots residing in this cloud and found that they did not disappear but migrated to other hosts within a day. They remained recognizable by the same TLS fingerprint JA4. For everyone involved in parsing and automation, this is a rare real-world experiment addressing two questions: what to do when infrastructure collapses, and why changing IPs and hosting does not alter a bot's "identity."
What Happened to Yandex
According to BleepingComputer, Yandex reported damage to three data centers due to drone attacks. Yandex did not name the culprit; media outlets, citing the BBC, link the strikes to Ukraine. The timeline is as follows:
- October 8 — Sasovo (Ryazan region): fire, site completely shut down;
- October 9 — Kaluga: operating with degradation, not a complete shutdown;
- October 11 — Vladimir: completely shut down.
On the Yandex Cloud status page, some services (console, API, IAM, databases, S3, Kubernetes) remained accessible but with performance issues, while Compute and AI Studio operated partially. The company stated that it could not provide reliable recovery timelines, considered the remaining resource configuration unstable, and recommended clients to use alternative disaster recovery plans. As of the publication of BleepingComputer (October 12), there were no recovery timelines or clarity regarding potential data loss.
What Cloudflare Observed: Traffic Dropped, Bots Did Not
On October 14, Cloudflare published an analysis of the outage from its network's perspective. Key figures include:
- On October 11, traffic from the Yandex Search network (AS13238) dropped by 99% from normal levels, while traffic from Yandex.Cloud (AS200350) fell by 90%;
- 99.5% of requests from AS13238 before the outage were automated, with 93.6% of bot requests being verified Yandex crawlers. This network accounted for about 7% of all bot requests from Russian IPs;
- In Yandex.Cloud, about 95% of assessed requests were bots, and none of them were verified. This represents about 2% of Russian bot traffic;
- Bot traffic from Yandex.Cloud decreased by approximately 40%, and scanning of WordPress plugins from this network dropped by 90%.
Then came the main point. Almost all bot requests from Yandex.Cloud were directed to a single Cloudflare client account in the gambling sector. Immediately after the outage on October 8, requests from Yandex.Cloud to this account dropped to zero — and identical requests from networks of other Russian hosts, Radist and Selectel, appeared right away. With the same JA4 TLS fingerprint, the same rare paths and headers, and the same non-standard User-Agent strings. The result over the week: Russian bot traffic to gambling accounts did not decrease but increased — from 167.7 to 170.1 million requests (+1.4%).
Cloudflare's conclusion was firm: physical infrastructure is static, while malicious automation is designed to migrate. The drop in HTTP traffic indicates an outage but does not mean that bots have stopped.
The Loud Version and Data: Why "Bots Went Silent" Was an Exaggeration
Simultaneously, the Ukrainian Center for Countering Disinformation (CCD) claimed that after the strike on Sasovo, the number of reports of suspicious accounts on Facebook and Telegram dropped by 83.6% in one day — from 4,032 to 660. However, as TechRadar analyzed, by October 10, activity returned to 4,585 reports, and by October 11, it exceeded pre-strike levels. Cloudflare did not find a significant shift: bot traffic from Russian IPs to the "post, reply, like" endpoints of one social network decreased by only 5.7%. Graphika also did not observe a loss of active accounts in the monitored communities. Researcher Renee DiResta in Lawfare described the story as beautiful but more akin to fiction than fact.
A separate lesson for analysts: on October 8, banks, retail, operators, and media outlets experienced failures across Russia, so any drop in "activity" on that day cannot be unconditionally attributed to bots. Aggregated traffic can easily mislead.
Lesson One: IP and Hosting Are Not a Bot's Identity
Cloudflare recognized the link "Yandex.Cloud → Radist/Selectel" not by addresses — the addresses and ASN changed completely. It was recognized by behavior and client fingerprint:
- JA4 — the hash of the TLS ClientHello: a set of ciphers, extensions, and protocol versions. It describes the program, not the network. The same Python script on a new server produces the same JA4;
- Rare paths and headers — the order and set of HTTP headers that are not found in regular browsers;
- Custom User-Agent — a unique string that serves as a label by itself.
The practical takeaway for legal parsing: changing the data center or IP pool does not make you "new" to an anti-bot system if the entire client stack remains the same. Conversely, if your crawler honestly identifies itself, behaves carefully, and does not hit sensitive endpoints, a stable fingerprint is not an issue. Problems arise when the stack appears as something that real users do not have: a declared Chrome with a TLS fingerprint from the requests library, an exotic UA, non-standard headers. We discussed in detail how this detection layer works in our analysis of JA4 and TLS fingerprinting in scraping.
Note another detail: bots migrated from one data center to others. For Cloudflare, this is still the same category of hosting ASN, which many sites have pre-existing distrust towards. The network is different — the risk profile remains the same.
Lesson Two: Infrastructure Must Be Transportable Within Hours
Malicious actors migrated within a day because their automation was initially portable. Honest teams that collect prices, monitor search results, or conduct analytics need such portability just as much. Yandex Cloud's recommendation to "use alternative disaster recovery plans" is only good if such a plan already exists. A minimal checklist includes:
- Code and configs — outside the cloud. Repositories, container images, and environment variables should be stored in a way that allows deploying a parser at another host with a single command.
- Second host in advance. An account, payment, and test server with an alternative provider in a different jurisdiction and region. Registering and passing verification on the day of the outage is too late.
- Output layer separate from computations. If requests to target sites go through a proxy provider rather than directly from the server's IP, migrating computations does not change either the geo, the type of IP, or the session history. The server can be moved, but for the site, you remain the same client.
- Data and queues — with replication. Parsing results and task states should be copied to another storage; otherwise, after an outage, you will have to start the crawl from scratch.
- Backup provider — truly different. A backup hosting or proxy provider should not turn out to be the same infrastructure under a different brand. We discussed how to check this for proxies in our article on why a backup proxy provider may turn out to be the same pool.
- Practice drills. Once a quarter, deploy the parser on the backup site and run a real task. A plan that has never been executed usually does not work in practice.
What Type of Proxy Solves What in Such a Situation
Proxies do not save you from a poor fingerprint — this is evident from the example in Cloudflare's analysis. However, they detach the "identity" of your requests from where the code physically runs:
- Residential proxies — for sites where hosting ASNs are pre-filtered or receive CAPTCHAs. When migrating servers, the exit remains on residential IPs of the required country.
- Data center proxies — for APIs and friendly sites where speed and price are important. These should also be kept with a provider independent of your cloud to ensure that a hosting outage does not take your exit IPs with it.
At the same time, proxies are just one layer. If the TLS stack, headers, and behavior of your client stand out, they will be recognized on any IP, just as the bots that migrated to Radist and Selectel were recognized.
What This Means for Website Owners
Cloudflare draws the opposite conclusion: ASN and traffic volume are unreliable indicators of a bot. Blocking a "bad" network works until the first migration. It is more reliable to look at behavior: common JA4 fingerprints across different networks, abnormal request frequencies, and WAF rules on sensitive endpoints, regardless of where the request originated. There is also a downside: 40.5% of Cloudflare clients responded to Yandex's crawler with a 403 code, and traffic from Yandex networks to news sites dropped by 44% during the outage — meaning legitimate indexing was primarily affected.
Conclusion
The Yandex outage served as a live test of two simple truths. First: infrastructure can disappear in a day, and the winner is the one who knows how to move it within hours — with code outside the cloud, a second host, and an output layer not tied to the server. Second: to an anti-bot system, you are your client stack, not your IP. A new data center with the same JA4 and the same User-Agent is the same bot at a new address. Build your parsing in a way that it can survive a platform change while looking equally neat on any IP.