Between 7 and 13 October 2026, two large Yandex networks were progressively knocked offline. By 11 October, Cloudflare measured traffic from Yandex's search network at 99% below its normal baseline, and from its cloud network at 90% below. On 14 October Cloudflare published what its own data showed happened to the automated traffic those networks had been sending, and the answer is a useful warning for anyone who reads a security dashboard.
Cloudflare's framing is the point: "aggregate traffic metrics can easily mislead." A graph showing traffic from a network falling to near zero tells you the network went down. It does not tell you what the traffic was, or whether it stopped.
Two networks, two different results
Cloudflare looked at the two networks separately, because they carried very different traffic.
The search network. Almost everything it sent was search crawling. In Cloudflare's words, "The drop in traffic consisted almost entirely of verified search crawlers indexing web pages, images, and site resources." When that network went offline, websites simply saw less indexing.
The cloud network. This is where the more interesting automation lived. Cloudflare'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." Bot traffic from that network fell by about 40%, and some attack-like categories fell much further. WordPress plugin probing fell 90%, and scanner-identified requests fell 93%.
Those two findings should not be merged. The crawlers really did stop. Some of the malicious traffic from the cloud network did fall. But one part of it did something else entirely.
The traffic that moved house
Cloudflare's clearest example is automation aimed at a gambling customer. Nearly all of the cloud network's bot requests were aimed at one gambling customer account. When the network was disrupted, those requests from it dropped to zero, and identical requests began arriving from other hosting networks, with the same TLS fingerprint, the same unusual request paths and headers, and the same custom User-Agent strings.
The total barely moved. Cloudflare reports that "Russian bot traffic targeting gambling accounts remained essentially flat over the week, moving from 167.7 million to 170.1 million requests (+1.4%)." As it puts it, "The automation never stopped running; the operators simply migrated their workloads to alternate cloud providers once Yandex.Cloud became unavailable."
So a site owner watching only "traffic from this network" would have seen a dramatic drop. A site owner watching the gambling automation itself would have seen almost no change.
What to ask about your own monitoring
Cloudflare draws the general lesson itself: "While malicious traffic may originate from a particular provider, it does not necessarily tell us who is responsible for the traffic." Understanding what happened, it says, "requires analyzing request behavior, rather than just overall traffic patterns."
If you look after a website or an application, a few questions follow from that:
- What is your alert keyed to? A rule or a chart built on where traffic comes from will show a "win" whenever a large provider has a bad week, even if nothing aimed at you has changed.
- Can you see behaviour, not just origin? The traffic that moved kept the same fingerprint, paths and headers. Those are the things that stayed constant; the source network was the thing that changed.
- Do you separate good automation from bad? Here, the biggest drop on one network was search crawlers, which most sites want. A single "bot traffic" number would have hidden that.
- When a graph improves suddenly, do you ask why? A drop you didn't cause is a question, not a result.
Source: Cloudflare, "Yandex outage: Data shows that instead of going dark, malicious bots went on the move" (published 14 October 2026, read 15 October 2026).