If your recovery plan calls for more virtual machines, Yandex Cloud has added a constraint: it has suspended quota increases for additional cloud resources. After a drone attack damaged its Vladimir data center on October 11, Yandex recommended alternative platforms for recovery. Its incident log describes the remaining infrastructure as unstable.
The outage has also become a debate about automated traffic. A Hacker News submission linking to Cloudflare Radar's Yandex network view had 554 points in MrKeyoor's October 11 news snapshot. That measures community attention. For developers deciding where to restore an application, the more useful evidence is the provider's account of which recovery options remain available.
A second shutdown with less room to recover
Yandex's October 11 incident record starts at 01:00 UTC. At 03:08, the company said a drone attack had damaged infrastructure in Vladimir and completely suspended the data center's operation. It reported no casualties. The notice recommended alternative disaster recovery plans and warned that support communications could be unstable.
An earlier incident in Sasovo began with a power outage on October 7 at 22:31 UTC. On October 8, Yandex attributed it to a fire following a drone attack and said that data center had been shut down. The affected availability zone was ru-central1-b. By October 10, its updates were still describing that zone as unavailable and computing-resource and disk quotas as manually managed.
The Sasovo log records recovery measures that required customer intervention. On October 9, Yandex said Kubernetes customers could move regional cluster management components into other zones, then create node groups there and transfer workloads. For fault-tolerant managed databases, removing hosts in the affected zone would make cluster management operations available again. Those instructions show that recovering an application can involve changes to its deployment, even when the platform has already shifted some load.
Yandex's availability-zone documentation says virtual machines and disks belong to individual zones, while cloud networks and buckets are global resources. That distinction matters when reading an outage notice: a resource's location determines its exposure. The existence of other zones doesn't tell you whether your particular application has running instances, usable data and enough capacity in them.
What the bot chart can tell you
The Radar page identifies its network filter as AS13238, Yandex LLC, and labels its bot-versus-human measure as a percentage of HTTP requests. An autonomous system number identifies a network. A result filtered to that network cannot be expanded into a measurement of all automated activity originating in Russia. The filter is part of the finding, even when a screenshot's caption leaves it out.
Cloudflare's HTTP-request documentation describes the observation point: complete requests reaching websites served by its CDN. This is traffic visible to Cloudflare. It doesn't provide a census of activity inside every social platform, nor does it identify the owner of every program making a request. A reduction can help investigate disruption in the observed network without answering those separate questions.
The classification has a specific technical meaning. According to Radar's bot-class rules, scores from 1 through 29 count as bot traffic, while scores of 30 or above count as likely human traffic. The labels describe how requests are classified. They supply no field for political affiliation, campaign membership or the text an account posts on a social network.
Cloudflare's broader bot-score explanation includes verified, non-malicious automation used by search engines and other applications. It also describes detection based on request features, including headers and browser signals. Calling a request automated therefore doesn't establish its purpose. A claim that an outage disabled a particular influence operation would need evidence linking that operation to the affected infrastructure and demonstrating what stopped.
Percentages need their denominators
Cloudflare documents several normalization methods. Radar usually returns percentages or normalized values rather than raw counts. Under MIN0_MAX, for example, values are expressed relative to the highest value in the response, with the minimum fixed at zero. A percentage derived from that series would describe a fraction of a selected peak. It wouldn't count machines, social accounts or people.
A bot share answers a different question: what proportion of observed requests was classified as automated. That share can change because bot requests change, because human requests change, or because both do. Cloudflare's HTTP examples distinguish summaries across a period from time series within it. Before using a chart to size an outage, preserve that distinction and identify whether the plotted measure is traffic volume or a traffic breakdown.
Even comparisons between normalized series need care. Cloudflare says min-max comparisons across locations or periods should use multiple series in the same request, so they share a scale. Two screenshots with independently normalized axes can make unequal volumes look similar. For this incident, traffic telemetry is useful alongside the shutdown notices; it can't establish the identity or intent of the missing traffic by itself.
Failover still needs somewhere to run
Yandex's guidance for instance groups during zonal incidents warns that an entire group in the affected zone may be unavailable. It recommends creating a group in a healthy zone and keeping a performance buffer for services that use instance groups. That buffer is operational capacity: surviving resources must be able to handle the work moved onto them.
The same guidance names Kubernetes node groups and Application Load Balancer resource units among the services built on instance groups. It also tells customers to take their own mitigation steps. An application team therefore needs to check the behavior of its configured services, rather than assume a regional label completes recovery. Yandex's incident guidance describes mechanisms and customer responsibilities, not a guarantee that every deployment will continue serving requests.
Yandex makes another useful distinction in its storage architecture documentation. High availability addresses individual foreseeable failures and uses spare components to restart resources. Disaster recovery covers the workflows and people needed after a larger disruption, including a data center fire. It calls for independent components so recovery remains possible when the production environment fails. A replicated deployment can still depend on services needed to manage or restore it.
For a team reviewing its own plan, that definition suggests a concrete exercise: identify the resources that must already exist outside the failed environment and the ones you'd have to create during recovery. Then check how you'd obtain the required data and access. This is an application of Yandex's independence requirement, rather than evidence that any particular customer's backup has failed. The October outage makes the provisioning step worth examining before the next rehearsal.
Recovery has to be checked service by service
The October 11 updates show partial restoration. At 08:14 UTC, Yandex reported S3 reads and writes available with possible slowdowns, compute partially available, and continuing problems with some Kubernetes clusters. Its 15:01 update still described limited functionality and recommended alternative platforms. An available console alone can't establish that an application's dependencies are working.
Yandex's network overview describes data centers and points of presence connected through a transport network, with outbound cloud traffic distributed across those points of presence. That architecture gives a further reason to avoid mapping one network-level traffic curve directly onto one building's recovery. The network measurement and the status of a customer's workload are different observations, each with its own scope.
Yandex scheduled its next incident update for October 12 at 08:00 UTC. Watch for changes to the quota suspension and service restrictions, then verify the operations your recovery plan requires. A traffic rebound would be useful corroboration, but a working restore path needs usable resources at the destination.