Can a Traffic Drop Prove Bots Went Offline? What Yandex Data Shows

No, and the most instructive recent demonstration of that answer comes from a single vendor’s dataset, which is worth saying up front: every event statistic in this article comes from Cloudflare’s October 14 analysis of the Yandex outage, produced by Cloudflare’s own bot classifier observing its own network, with no independent replication in the available evidence. That caveat does not make the data useless. It makes the article about how to read it. Because what the data shows, read carefully, is that a traffic chart collapsing toward zero proves the network went down and almost nothing else, while the interesting question (were the automated actors disrupted, or did they move?) requires a completely different measurement layer. Cloudflare’s own framing is blunt: “A drop in overall HTTP traffic only confirms that the network went down. It does not reveal whether malicious or evasive bots were disrupted.”

If your team watches aggregate dashboards after an outage, a takedown, or a provider deplatforming and someone asks “did we knock the bots offline?”, the Yandex event is a worked example of why the honest answer is “we don’t know yet, and here is the procedure that would tell us.”

What actually happened to Yandex traffic, October 7–14

Between October 7 and 11, 2026, reported drone strikes hit three Yandex facilities in Russia (Sasovo, Kaluga, and Vladimir, per the table in Cloudflare’s post), progressively knocking data centers and network capacity offline. The network effect, as measured by Cloudflare, was severe: on October 11 “traffic plummeted to 99% below baseline for Yandex Search (AS13238) and 90% for Yandex.Cloud (AS200350),” per the same post, and both ASNs remained 86–90% below normal through October 13 (Cloudflare). As of October 14 at 18:00 UTC, traffic stood at 85% of normal, again per Cloudflare. Anything about recovery after that timestamp is [unverified].

Charts of that collapse circulated quickly, and per Cloudflare’s post, early internet commentary read them as evidence that Russian bot farms had been knocked offline. That reading is exactly the failure mode this article is about. The volume drop is real. The conclusion drawn from it does not follow.

The baseline problem: over a third of HTTP requests are already automated

Before any event interpretation, you need a baseline, and the pre-strike numbers complicate the intuitive picture. Cloudflare reports that “before the strikes, automated requests accounted for 36.1% of all HTTP traffic observed globally across Cloudflare’s network, and 35.8% of traffic from Russian IP addresses.” (per the same post) So more than a third of what crosses a large network is already non-human on an ordinary day. (Note that the post’s own daily table, computed on a total-request basis, shows a different automated-share baseline of 39.4% for October 1–6, with daily values of 39.2–39.6% through October 13 and a second measure falling from 50.4% to 42.1% (Cloudflare). The post does not reconcile the prose figure with the table; cite each with its context rather than mixing them.)

Two things follow. First, “bot traffic” is not a synonym for “malicious traffic”; it is a large, heterogeneous category that includes the crawlers that make search engines work. Second, a global automation share that stays roughly flat while one country’s biggest network collapses is itself evidence about where the automation actually lives.

Two ASNs, two stories

The analytical move that rescues the Yandex data from the aggregate-chart trap is splitting it by autonomous system. As Cloudflare explains: “aggregate traffic metrics can easily mislead. There are two autonomous system numbers (ASNs) associated with Yandex: AS13238 is used by Yandex’s search engine, while AS200350 runs its cloud services.” Same company, same event, two almost opposite automation profiles.

On the search ASN, the automation was legitimate and declared. Cloudflare classified “99.5% of its requests as automated, and 93.6% of its bot requests as Verified.” Sampled requests broke down as 78.1% verified YandexBot, 11.5% YandexRenderResourcesBot, and 1.9% YandexImages, per the same post: a search crawler fleet, not a bot farm. The commercial consequences of losing it landed unevenly (Cloudflare): Publishing and Newspapers saw the steepest Yandex-traffic drop at −44%, about 90% of pre-event news-site traffic from this ASN was YandexBot, and 40.5% of Cloudflare customers had been serving it HTTP 403 per Cloudflare because site owners blocked the crawler anyway. In network terms, AS13238 supplied about 7% of Russia-origin bot requests and only 0.05% of the global bot total (Cloudflare).

On the cloud ASN, the mix looked like a different population entirely, per Cloudflare: “Approximately 95.0% of its scored requests were bots, but none of its observed bot requests were verified by Cloudflare.” These bots behaved like software applications, with nearly two-thirds of requests sending data to sites and some self-identifying as JavaScript, Python, or Go programs, and the ASN supplied about 2% of Russia-origin bot requests.

All figures in the table are from Cloudflare’s post. The comparison is the point: a single “Yandex traffic down 90%+” headline flattens a verified-crawler outage and an unverified-automation disruption into one number, and those two events have opposite implications for your abuse dashboards.

Migration, not disappearance: what the Yandex.Cloud deltas show

Here is where the counter-evidence matters, because the strikes did cause real short-run disruption, and pretending otherwise would be as sloppy as the “bots offline” claim. Cloudflare reports: “Following the reported strikes, bot traffic from Yandex.Cloud fell about 40%. Several attack-like categories showed especially sharp declines. For example, WordPress plugin probing fell 90% and scanner-identified requests fell 93%.” And, per the same post, “Interestingly (and tellingly), Cloudflare customer blocks on Yandex.Cloud traffic also fell 70% during the event period, suggesting that proportionately less malicious traffic was even hitting the Cloudflare WAF from this ASN.”

Read those numbers carefully. The post reports a roughly 40% event-period decline in Yandex.Cloud bot traffic (per Cloudflare) and, separately, a 90%-below-baseline trough for total ASN traffic on October 11 per the same post; it does not state matched measurement windows, so no share shift can be derived from the pair. But the migration conclusion does not rest on those deltas or on the 70% block decline, which the post frames as a separate observation (Cloudflare). It rests on a directly observed relocation. Nearly all of Yandex.Cloud’s bot requests targeted one gambling customer account, and “Immediately following the October 8 disruption, bot requests from Yandex.Cloud to this account dropped to zero. Simultaneously, identical requests began appearing from other Russian hosting ASNs, including Radist and Selectel.” The incoming traffic “maintained an identical fingerprint across providers”: the same JA4 TLS client fingerprint, the same uncommon request paths and HTTP headers, the same custom User-Agent strings. Russian bot traffic targeting gambling accounts “remained essentially flat over the week, moving from 167.7 million to 170.1 million requests (+1.4%),” per Cloudflare, so the operators kept running and changed hosts. Hence the post’s summary: “There was a decline in malicious activities like vulnerability scanning and probing, but high-volume automation did not vanish — it simply migrated to other hosting providers.”

What keeps that from being the last word is scope, not method. This is a measured migration of one actor population in one vertical, seen by one classifier on one network. The volume deltas are consistent with the same story, and the daily table shows the global automated share nearly flat at 39.2–39.6% through October 13 (per Cloudflare), but gambling is the only vertical where the post documents the hop itself. Whether the scanning and probing populations that fell 90–93% also moved, rather than stopped, is not separately shown (Cloudflare). And a determined actor evading that classifier would be invisible to exactly this analysis, a point the error-bars section below returns to.

A replicable procedure for the next takedown

The Yandex event generalizes into a three-step procedure you can run on your own telemetry the next time an infrastructure event, deplatforming, or takedown produces a dramatic volume chart.

1. Classify per ASN before concluding anything. Establish the network role (search crawler, cloud hosting, residential proxy, CDN) and the verified-bot share of automated requests for each affected ASN. The Yandex data shows why both matter (Cloudflare): 99.5% automated with 93.6% verified describes a crawler outage; ~95% bots with zero verified describes a hosting network full of unattributed software. The same “network down” event means opposite things for those two profiles. This is not exotic methodology; classification is where network monitoring has always done its analytic work. As a paper on class-incremental learning in mobile traffic classification puts it in its introduction, “Traffic classification (TC) is at the core of any network traffic monitoring system, and a pillar for traffic management, cyber security, quality-of-experience monitoring, and other strategic activities for network operators.”

2. Track actor families by request behavior, not by origin. If automation migrated, origin-ASN filtering will lose it by definition. The workable alternative is clustering request behavior so the same actor family is recognizable from a new host. Honeypot research demonstrates the technique concretely: concatenate an actor’s request log, tokenize it, vectorize with n-grams, and apply agglomerative clustering. In the bot-loader study, “The request logs generated by the local Hajime scanner are located closely with other scanners and Anna-senpai’s Mirai loader is located along with its variants in the yellow branch.” That is family identification independent of originating host, validated against a control group of known samples. Cloudflare’s post ran its own version of this check and caught the hop: after Yandex.Cloud requests to one gambling account dropped to zero, identical JA4 TLS fingerprints, request paths, headers and custom User-Agent strings resurfaced from Radist and Selectel, with gambling-targeted Russian bot traffic flat week-over-week at 167.7 million to 170.1 million requests (+1.4%) (Cloudflare). Applied to your WAF logs: cluster the pre-event Yandex.Cloud request population, then look for those clusters reappearing under other hosting providers’ ASNs in the days after the event. If they resurface, you have migration with evidence. If they do not, you have a stronger (still not conclusive) disruption claim.

3. Reset baselines per ASN, not globally. The traffic-classification literature also warns that classifiers degrade when the traffic mix shifts unless they are maintained, so a global baseline reset after a mix-changing event bakes the event into your definition of normal. Reset the fraud and abuse baselines for the affected ASN scope only, and only after step 2 tells you whether the actor population actually changed or just moved.

What aggregate volume can never establish

Even a perfect per-ASN breakdown leaves one question permanently open: who is responsible. Cloudflare states the limit explicitly: “While malicious traffic may originate from a particular provider, it does not necessarily tell us who is responsible for the traffic” (Cloudflare). Origin ASN tells you whose address space carried the requests. It does not tell you who operated the botnet, rented the VPS instances, or paid for the scanning. Any report that moves from “traffic from AS200350 fell” to “the operators behind it were disrupted” has crossed from measurement into speculation, and the Yandex data, for all its richness, cannot support that step either.

Error bars on the instrument

Every bot-share number in this article is the output of one classifier, and classifier error is not a formality. Research on biasing binary classifiers toward fewer false negatives or false positives finds that conventional methods (threshold shifts, loss weighting, augmentation) “are able to change the recall or precision from 1-2% at most” (arXiv:2204.02526). Residual misclassification is not cheaply tunable away, so a figure like “95.0% of scored requests were bots” carries error bars the vendor does not publish.

The evasion problem is worse. Work on adversarial attacks against malware detectors found that hardening does not rescue accuracy: “Adversarial deep ensemble cannot serve as a remedy, and even reduces the detection accuracy on both malicious and benign examples” (arXiv:2006.16545), with all tested models failing against mimicry-style attacks that imitate benign samples. A bot operator who mimics verified-crawler or browser behavior is precisely the actor a classifier-based migration analysis would miss. And the underlying difficulty is structural, not specific to one vendor: as research on bot detection in open-source communities notes, “Identifying bots is a challenging task due to their actions’ similarity to those of a human” (BotHawk, arXiv:2307.13386); that paper’s own answer is a behavioral-feature ensemble that outperforms prior models for open-source bot detection.

The practical consequence: treat “93.6% verified” and “zero verified” (Cloudflare’s figures) as one instrument’s readings. These figures come from a single instrument, and the material cited here includes no independent bot-share measurement, so these numbers have no second instrument to check against. If a number will drive a takedown announcement or a board-level claim, it needs a second instrument first.

The playbook, stated plainly

When the next volume chart collapses, the defensible sequence is:

1. Report network disruption as measured: which ASNs, how far below baseline, for how long. That is what the chart proves.
2. Classify the affected ASNs by role and verified-bot share before saying anything about actors (Cloudflare).
3. Cluster request behavior pre-event, then hunt for those clusters on other providers’ infrastructure before claiming disruption.
4. Reset fraud and abuse baselines per ASN, scoped to what actually changed, and only after step 3.
5. Attach the instrument’s name to every bot-share figure, and say out loud that no independent replication exists when that is true.

I would hold any “bots knocked offline” claim to that standard regardless of how clean the chart looks, and the Yandex case shows the cost of skipping it: the early chart-led claims pointed one way while the per-ASN data, from the same event and the same network, pointed the other.

Limitations

This analysis inherits its boundaries from its evidence. The migration finding rests on Cloudflare’s own telemetry, including the fingerprint-matched gambling relocation, with no independent post-mortem or rival measurement in the available material, and evasion research shows the instrument itself can be gamed by actors who mimic benign traffic. The two automated-share baselines in the post (36.1% in prose, 39.4% in the daily table, per the same source) are not reconciled by the post and should not be merged. Recovery state beyond October 14, 18:00 UTC is unknown. What survives those limits is the procedure: volume proves the network went down; per-ASN classification, behavioral clustering, and scoped baseline resets are what it takes to say anything more.

Frequently Asked Questions

Did the Yandex outage prove that malicious bots were taken offline?

A drop in overall HTTP traffic only confirms that the network went down. It does not reveal whether malicious or evasive bots were disrupted.

What happened to the bot traffic from Yandex.Cloud after the strikes?

Following the reported strikes, bot traffic from Yandex.Cloud fell about 40%. Several attack-like categories showed especially sharp declines. For example, WordPress plugin probing fell 90% and scanner-identified requests fell 93%.

How did the bot operators respond to the Yandex.Cloud disruption?

Immediately following the October 8 disruption, bot requests from Yandex.Cloud to this account dropped to zero. Simultaneously, identical requests began appearing from other Russian hosting ASNs, including Radist and Selectel.