A Yandex data center outage has disrupted cloud and digital services after multiple drone attacks damaged three of the company’s data centers in Russia within days.
Yandex confirmed that its Sasovo data center was seriously damaged during the night of October 7–8, 2026 and completely shut down. A second attack struck its Kaluga facility on October 9, knocking part of its infrastructure offline.
The company later confirmed that another drone attack damaged its Vladimir data center during the night of October 11, forcing that facility to suspend operations completely.
No employees were reported injured in the incidents.
Following the Vladimir attack, Yandex Cloud’s official status page described the remaining resource configuration as unstable and placed the platform in emergency operating mode.
For broader coverage of how geopolitical conflict can affect digital infrastructure and technology services, see our Nation-State Cyber Warfare and APT Threats 2026 Hub.
Key Takeaway
Three Yandex data centers were damaged over several days, with Sasovo and Vladimir completely shut down and part of the Kaluga infrastructure taken out of service. Yandex Cloud warned that its remaining infrastructure was unstable and recommended that customers activate alternative disaster-recovery plans. The incident involves physical damage to data-center infrastructure and should not be described as a malware attack or network intrusion.
Three Yandex Data Centers Damaged Within Days
The disruption began during the night of October 7 to October 8, when Yandex said its data center in Sasovo was seriously damaged in a drone attack.
The company completely shut down the facility while emergency services and technical teams assessed the damage.
On October 9, Yandex confirmed another attack on its Kaluga data center. Part of the infrastructure at that facility was taken out of service.
A third incident followed during the night of October 11, when Yandex said its data center in Vladimir was damaged by another drone attack.
The Vladimir facility was also completely suspended.
Yandex said there were no casualties in the incidents and that emergency teams and company specialists were working at the affected sites.
Yandex Cloud Entered Emergency Mode
The impact extended beyond the physical facilities.
After the Vladimir data center was disabled, Yandex Cloud warned customers that its remaining resource configuration should be considered unstable.
The company’s official status page said the platform was operating in emergency mode and recommended that customers use alternative disaster-recovery plans on external infrastructure.
Yandex also warned that technical-support communication channels could be unstable and that information on its status board might appear with delays.
Which Yandex Cloud Services Were Affected?
Yandex Cloud’s status updates showed different levels of availability across the platform following the incidents.
At one point, the company reported:
- Yandex Cloud Console and API — available
- Compute — partially available
- Managed databases — most high-availability clusters failed over, while some could operate in read-only mode or remain unavailable
- S3 storage — available for reading, with possible write issues
- Managed Service for Kubernetes — partially available or under assessment
- Identity and Access Management — available
- Yandex Monium — unavailable during reported status updates
Yandex cautioned that other services could also experience disruption while recovery work continued.
Users Reported Problems Accessing Cloud Files
The outage also affected some users attempting to access data stored on Yandex services.
Reports from affected customers described problems downloading previously uploaded files and retrieving stored content.
Some users encountered HTTP errors or failed requests while attempting to access cloud-hosted files.
However, inability to download a file during an outage does not establish that the underlying data has been permanently deleted.
Yandex has not publicly confirmed irreversible customer-data loss from the affected facilities.
There Is No Confirmed Evidence of a Cyber Intrusion
The Yandex incident is important for cybersecurity and infrastructure resilience, but its nature should be described accurately.
The available official information points to physical damage to data-center infrastructure caused by drone attacks.
There is currently no public evidence that the service disruption resulted from:
- Malware
- Ransomware
- Compromised administrator credentials
- Unauthorized access to customer accounts
- Data exfiltration
- A software vulnerability
For that reason, describing the incident simply as a “Yandex cyberattack” would be misleading.
Sasovo Data Center Was Completely Shut Down
Yandex described the Sasovo facility as seriously damaged following the first attack.
The company completely suspended operations at the site and said it was continuing to assess the condition of the equipment.
In its official statement, Yandex said it was difficult to estimate when damaged equipment could be returned to service.
The uncertainty around physical infrastructure makes restoration different from recovering from an ordinary software outage, where operators may be able to restart systems or roll back a configuration change.
Kaluga Facility Lost Part of Its Infrastructure
The Kaluga data center was struck the following day.
Yandex said part of the site’s infrastructure went out of service but did not initially report a complete shutdown similar to Sasovo.
The company continued assessing the remaining capacity while attempting to maintain services for customers.
Vladimir Attack Triggered Further Cloud Disruption
The Vladimir incident created additional pressure on Yandex’s remaining cloud infrastructure.
Yandex Cloud said the site’s operation was completely suspended following damage caused by the drone attack.
After the shutdown, the company explicitly warned customers that the remaining resource configuration was unstable.
This is why its status update went beyond a normal service-degradation notice and recommended that businesses activate recovery plans outside the affected platform.
Why Yandex Recommended External Disaster Recovery
Disaster recovery normally assumes that an organization can shift workloads away from damaged infrastructure.
That can mean moving an application to another availability zone, another region or a completely separate cloud provider.
In this case, multiple Yandex facilities were affected in quick succession, reducing the amount of healthy infrastructure available for failover.
Yandex therefore advised customers to use alternative recovery environments rather than depending exclusively on resources inside the affected cloud platform.
The warning is particularly important for organizations whose backups exist inside the same provider environment as their production workloads.
The Outage Highlights Cloud Concentration Risk
Cloud platforms are designed with redundancy, but redundancy is most effective when failures remain isolated.
When multiple physical facilities experience disruption at nearly the same time, the available capacity for recovery can shrink rapidly.
Organizations running critical workloads should therefore understand where their services, replicas and backups are physically and logically distributed.
A backup stored in the same failure domain as the production environment may not provide sufficient protection during a large infrastructure incident.
What Businesses Using Yandex Cloud Should Do
Yandex itself recommended activating alternative disaster-recovery plans while the platform remains unstable.
Organizations using affected services should consider the following steps:
- Check the Yandex Cloud status page for current service availability
- Identify workloads dependent on affected zones or services
- Verify that backups remain accessible
- Confirm that critical data exists outside the affected infrastructure
- Fail over essential services to an alternate environment where possible
- Test application dependencies after migration
- Monitor IAM, database and object-storage availability
- Avoid assuming a successful backup until restoration has been tested
- Maintain communication plans that do not depend on a single cloud platform
Multi-Region Is Not Always Enough
One of the lessons from large infrastructure outages is that logical redundancy does not always equal independent resilience.
Two cloud zones may be technically separate while still depending on shared networking, power, control-plane services or other infrastructure.
Organizations running high-value services should map those dependencies rather than assuming that different availability zones automatically eliminate correlated failure.
For the most critical systems, an external disaster-recovery environment can provide an additional layer of protection.
Data Availability and Data Loss Are Different Problems
Reports of inaccessible Yandex Disk or cloud-hosted files have raised understandable concerns about customer data.
However, data being temporarily unavailable does not necessarily mean it has been destroyed.
A service can fail to retrieve information because storage systems, metadata databases, authentication services, networking layers or control systems are unavailable even when the underlying data still exists.
At the time of writing, Yandex has not publicly confirmed permanent loss of customer files related to the three damaged data centers.
Until the company provides further information, permanent data loss should not be presented as an established outcome.
Why Data Centers Are Part of Critical Digital Infrastructure
The Yandex outage shows how physical and digital infrastructure are increasingly connected.
A modern data center can host cloud compute, databases, storage, identity services, AI workloads and consumer platforms at the same time.
Damage to the underlying facility can therefore affect far more than the servers physically located inside the building.
Applications, businesses and users located far from the damaged site can experience failures because their services depend on infrastructure running there.
Frequently Asked Questions
What caused the Yandex data center outage?
Yandex says drone attacks damaged its data centers in Sasovo, Kaluga and Vladimir. Sasovo and Vladimir were completely shut down, while part of the Kaluga facility’s infrastructure was taken out of service.
Was Yandex hacked?
There is currently no public evidence showing that the outage was caused by malware, stolen credentials or a network intrusion. Official Yandex information describes physical damage to data-center infrastructure.
Which Yandex Cloud services were affected?
Yandex reported partial availability for Compute and Kubernetes, issues affecting some databases and S3 writes, while IAM remained available. Some other services experienced varying levels of disruption.
Did Yandex lose customer data?
Yandex has not publicly confirmed permanent customer-data loss. Some users reported being unable to access stored files, but temporary unavailability does not prove that those files were deleted.
Why did Yandex recommend alternative disaster recovery?
After the Vladimir shutdown, Yandex described the remaining cloud resource configuration as unstable and advised customers to activate recovery plans using alternative infrastructure.
When will Yandex services fully recover?
Yandex has said that assessing damaged infrastructure is difficult and has not provided a reliable timeline for full equipment restoration.
Final Takeaway
The Yandex data center outage demonstrates how quickly physical infrastructure damage can become a large-scale digital-service problem.
Three data centers were damaged within several days, two were completely shut down and Yandex Cloud entered emergency operating mode as engineers worked to stabilize the remaining infrastructure.
For customers, the most important issue is not only whether individual services are currently online, but whether critical workloads and backups can survive the loss of multiple infrastructure locations.
The incident is also a reminder that disaster recovery should extend beyond a single facility, availability zone or cloud platform when business continuity depends on uninterrupted access to digital services.
