Yandex Cloud Outage Leaves Customers Locked Out of Their Files

Drone strikes have knocked three Yandex data centers offline in four days, and the resulting Yandex cloud outage has left customers unable to reach their stored files. The facilities at Sasovo and Vladimir stopped operating completely. A third site in the Kaluga region limps along at reduced capacity. Yandex confirmed the damage and reported no injuries, but it cannot tell customers when any of it comes back.

Three Data Centers Damaged in Four Days

The first strike hit Yandex’s facility in Sasovo, in the Ryazan region southeast of Moscow, during the night of October 8. The attack caused serious damage and started a fire, and operations at the site halted entirely. Sasovo also housed two of the three supercomputers Yandex uses to train its AI models, so the damage cuts into research capacity as well asuptime.

A second attack followed on October 9 at a facility in the Kaluga region, southwest of Moscow. That site survived in partial form but now runs well below normal capacity. On October 11, a third strike damaged the data center in the Vladimir region, around 180 kilometers east of the capital. Yandex suspended operations there completely.

Ukrainian forces reportedly carried out the strikes, targeting infrastructure that Russian businesses and government bodies lean on daily. Yandex reported no injuries at any of the three sites. Much of the country’s internet backbone runs through the company. It operates search, maps, ride-hailing, payments, email, consumer storage and business cloud services under one roof.

Which Services Still Run, and How Well

The Yandex cloud outage has pushed the platform into what the company itself calls emergency mode. Its status page describes the remaining resource configuration as unstable, and it warns that even support channels may prove unreliable. No restoration estimate exists.

The latest update lists Console, API, IAM, Container Registry, managed databases, S3-compatible object storage and Kubernetes asavailable but degraded. Compute, AI Studio and the platform’s security services run only partially. One service, Monium, remains fully offline.

Consumer products took the visible hit. Ride-hailing through Yandex Go, maps, payments, Yandex Music, Telemost and the Alisa assistant all failed or degraded as the cloud outage spread across Russian cities. Search and Alisa have started returning. The platform underneath them still runs in limited mode.

Customers Report Files They Cannot Retrieve

The sharpest complaints in the Yandex cloud outage concern stored data rather than compute. Customers began reporting problems on October 8, describing backups on Yandex Disk that displayed without thumbnails and files that refused to download. Attempts to open those files returned HTTP 302 redirects, 504 gateway timeouts and 500 server errors.

That pattern suggests an object store whose metadata still resolves while the underlying storage no longer answers. Users can see that their data exists, but they cannot pull it back out. For anyone treating Yandex cloud storage as a backup target, the outage has turned a recovery tool into a question mark.

Yandex has stayed silent on the possibility of permanent data loss. Its status updates deal with availability and say nothing about integrity, which leaves customers without an answer to the question that matters most. The company has not ruled out losses either. Nobody outside Yandex currently knows.

Why Multi-Zone Redundancy Did Not Hold

Yandex Cloud replicates customer workloads across availability zones inside a single region, ru-central1. Those zones sit in separate buildings, which covers the failure modes cloud architects plan for. A power loss, a cooling failure, a severed fibre run, a fire in one hall: the design handles those.

But the zones also sit a few hundred kilometers apart in central Russia. A threat that reaches one site can reach the others within days, and that is exactly what played out. Redundancy spread across a single geography defends against accidents, not against a campaign treating a whole region as its target set.

Teams running multi-zone setups on Yandex Cloud were following the documentation when the outage hit them. Their architecture held up against every scenario its designers anticipated, and then met one they did not. That gap between designed resilience and real resilience is where recovery plans quietly fail.

When the Provider Tells You to Fail Over Elsewhere

The most consequential line in Yandex’s own communications is its advice to customers: use any other alternative disaster recovery plans. A provider telling clients to move onto different infrastructure, with no estimate of when it can take them back, inverts the assumption behind most recovery planning. For business customers, that single sentence turned the Yandex cloud outage from an availability problem into an architecture problem.

Plenty of disaster recovery strategies treat the provider as the constant and the workload as the variable. Backups land in a second region of the same platform. Failover targets run on the same vendor’s compute, and the runbook assumes a console that still responds. When the vendor itself becomes the failure, those plans have nowhere to point.

Cross-provider recovery costs more and takes longer to build, so many teams defer it indefinitely. The Yandex cloud outage puts a number on that deferral. Customers with a second provider already configured spent this week moving traffic. Everyone else spent it refreshing a status page.

The Wider Lesson From the Yandex Cloud Outage

The specific cause here sits well outside the threat models most organizations write. Few companies in Europe or North America plan for drone strikes on their provider’s halls, and few need to. But the failure mode generalizes far beyond the circumstances that produced it, because any event that removes several facilities in one region lands the same way.

Flooding, grid collapse, regional conflict, a sabotage campaign against cables or substations: each one hits single-region architecture exactly as this Yandex cloud outage did. The questions worth asking do not change. Where does your data physically sit? How far apart are those sites, and can you restore anything without the vendor’s control plane responding?

For many teams, the honest answer is that they have never tested it. A recovery plan nobody has exercised against the total loss of a provider offers reassurance on paper and little else. Yandex customers are learning that distinction this week, and the next set of customers will not get to choose their timing either.