Three Yandex Data Centers Taken Offline in Four Days, Disrupting Cloud Services for 64,000 Business Customers

Key zones of Yandex Cloud were rendered unavailable as facilities in Sasovo, Kaluga, and Vladimir went dark within a single week — sending shares lower on the Moscow exchange and interrupting ride-hailing, payments, and delivery services for millions of users

Yandex, the technology company that operates Russia’s largest search engine, cloud platform, and consumer digital services, is working to restore operations after three of its six major data centers were taken offline within four days in October. The incidents affected facilities in Sasovo, Kaluga, and Vladimir, collectively representing roughly 115 megawatts of installed capacity and a substantial share of the company’s cloud computing and AI training infrastructure. According to company statements and service alerts, no employees were injured, but the operational and commercial consequences have been significant and are still being assessed.

This report examines what is publicly known about the infrastructure disruption, the technical architecture that was affected, the measurable economic fallout, and what the episode reveals about the resilience assumptions underpinning modern cloud platforms. All figures and statements below are drawn from Yandex’s own disclosures, its status pages, and reporting by other established outlets.

What Yandex Operates, and Why the Loss of Three Sites Matters

To understand the scale of the disruption, it helps to understand the concentration of Yandex’s infrastructure. The company runs six major data centers across Russia, supported by a network of edge nodes and points of presence. These facilities host not only Yandex’s own consumer products such as Search, Maps, Mail, the Alice assistant, Yandex Go for ride-hailing and delivery, and Yandex Pay for digital payments, but also Yandex Cloud, the public cloud platform that thousands of external businesses depend on for compute, storage, and managed services.

As of mid-2026, Yandex Cloud reported approximately 64,000 business customers, a figure disclosed in the company’s financial reporting. More than a third of the largest companies listed in the RBC-500 ranking — a widely cited index of Russia’s biggest firms by revenue rely on Yandex Cloud for some portion of their digital operations. That dependency is the reason a physical infrastructure event at three sites can propagate into consumer-facing outages across an entire region within hours.

The three affected facilities were not interchangeable. Each hosted a distinct mix of workloads, and the way Yandex’s internal architecture distributes services across sites determined which products degraded and which continued operating.

Facility-by-Facility: What Went Offline and When

Sasovo, Ryazan Oblast – October 7–8

The first facility to be taken offline was the Sasovo data center in the Ryazan region, southeast of Moscow. The site opened in 2014 and is rated at approximately 12 megawatts. It housed two of Yandex’s three high-performance computing clusters used for large-scale AI model training. According to the company’s service notifications, operations at the site were suspended, and internal teams were moved to contingency procedures. Sasovo is also understood to host a meaningful share of Yandex Cloud’s general-purpose compute capacity for the central Russian region.

The loss of Sasovo removed a large block of GPU-based training capacity from Yandex’s available pool. Training runs for large language models are typically scheduled weeks in advance and occupy entire clusters for extended periods; interrupting a run does not merely pause it, but in many cases invalidates work in progress, requiring the run to be restarted from an earlier checkpoint or from scratch.

Kaluga Oblast – October 9

Two days later, Yandex’s largest data center in Russia — located in the Grabtsevo industrial park in Kaluga Oblast, southwest of Moscow was affected. The Kaluga complex is the company’s flagship facility and the most recently built of the three. It spans roughly 130,000 square meters and was designed to accommodate more than 3,800 server racks at up to 15 kilowatts per rack, with a planned power capacity meaningfully larger than the company’s older sites. It was built specifically to expand Yandex Cloud’s regional capacity, including an additional availability zone.

According to Yandex’s own statements, several modules of the Kaluga facility were rendered inoperable. The company confirmed that no employees were injured and that emergency services were present at the site. Because Kaluga was purpose-built to host a portion of Yandex Cloud’s regional footprint, its partial loss directly reduced the number of independent failure domains available to the platform — a point that becomes important when examining why the remaining sites could not absorb the displaced workload.

Regional officials separately reported that a number of customers in the surrounding area lost electricity supply during the same period, though they did not attribute the outages to the Yandex facility specifically.

Vladimir Oblast – October 11

The third facility to go offline was the Vladimir data center, east of Moscow. This site housed the third of Yandex’s three high-performance computing clusters. In its service alert, the company stated that operations at the facility had been “completely suspended,” that the “remaining resource configuration is considered unstable,” and that the platform was running in emergency mode. Yandex also warned that technical support communications could be disrupted while teams assessed the state of the equipment.

The Vladimir site supports, among other things, the backend infrastructure for Yandex Pay. The company’s fintech division confirmed publicly that the payment platform was affected and that restoration work was underway.

The Technical Picture: Why Three Sites Broke a Six-Site Architecture

The most instructive aspect of this episode is not the loss of any single facility but the fact that losing three of six exceeded the platform’s ability to compensate. Yandex Cloud, like most large cloud providers, is built around the principle of availability zones i.e. physically and logically isolated groups of infrastructure within a region. Workloads are distributed across zones so that the failure of any one zone can be absorbed by the others.

That model has a well-understood limitation, and this episode illustrated it precisely. Redundancy across N zones is only effective while the surviving zones have enough headroom to absorb the displaced load. Under normal operations, each zone runs at a utilization level that leaves room for one, perhaps two, simultaneous failures. It is not economically rational to build every zone with enough spare capacity to absorb half the platform’s total load, because that capacity would sit idle almost all of the time.

When three zones are removed from service within four days, the surviving three inherit a workload they were never dimensioned to carry. The result is what Yandex described in its own customer communications: a degraded, “unstable” configuration in which the company advised customers to activate disaster-recovery plans rather than rely solely on internal failover between Yandex Cloud’s own zones. That advisory was notable because it effectively acknowledged that intra-platform redundancy had been exhausted.

External telemetry corroborated the internal picture. Internet monitoring organisation Netblocks reported that Yandex Cloud’s network connectivity had fallen to roughly 30 percent of normal levels on October 11. Yandex’s status page showed widespread degradation across the platform, with partial availability reported against a backdrop of ongoing outage indicators. In a subsequent update, the company stated: “The Yandex Cloud platform is still operating in a limited mode. Our specialists continue restoration work around the clock. The technical support team receives an increased number of requests, so the response time can be increased.” Customers were advised to use alternative sites for hosting and to reserve resources in advance — guidance that no cloud provider issues lightly, given its commercial implications.

The High-Performance Computing Dimension

Separately from the cloud platform, the three affected sites housed Yandex’s three top-tier high-performance computing clusters, which had appeared in the TOP500 ranking of the world’s most powerful systems as of June 2026. These clusters are used to train the company’s AI models, including the systems behind its search ranking, translation, advertising targeting, and the Alice assistant.

Each cluster is built around AMD EPYC host processors and NVIDIA A100 accelerators connected through high-speed InfiniBand networking, an architecture that allows thousands of accelerators to operate as a single coherent training system. Yandex has not disclosed the condition of any of the three clusters, and it has not confirmed whether any training capacity remains available. Independent Russian technology outlets have reported that restoring systems of this class is substantially more difficult than repairing a building, citing both the difficulty of procuring replacement accelerators and the specialised integration work required to bring a large training cluster back to production.

This distinction matters commercially. Cloud compute can, in principle, be rehoused in third-party facilities on relatively short notice. Large-scale AI training capacity cannot. It depends on a specific combination of accelerator supply, high-bandwidth interconnect, and power and cooling density that most general-purpose colocation sites are not configured to provide.

Market Reaction: Yandex Shares Fall on the Moscow Exchange

The financial market response was immediate. Yandex shares declined by more than 4 percent on the Moscow exchange as reports of the Kaluga disruption circulated, and the decline extended as the Vladimir facility was taken offline. Russian financial outlet Fontanka reported that the shares had lost close to 4 percent of their value by October 11, with quotations around 3,355 rubles, while Kommersant reported a cumulative decline approaching 6 percent following the third facility outage. Reuters independently reported the share movement and the broader investor concerns.

Analysts framed the risk as extending beyond the immediate loss of revenue from interrupted services. Maryana Lazaricheva, head of equity research at T-Investments, told Reuters that the exposure includes “not only the potential temporary unavailability of Yandex services and lost revenue in specific segments but also the company’s extensive base of B2B clients.” She noted that Yandex could shift some workloads to its remaining sites, but cautioned that if disruptions continue, that option ceases to be available.

That is the crux of the commercial risk. Consumer-facing outages are visible and recoverable — users generally return once a service is restored. Enterprise cloud contracts are different. They carry service-level agreements, uptime commitments, and, most importantly, a switching calculation. A business that migrates its workloads to a competing provider rarely migrates back quickly, and the decision is typically made not on the basis of a single outage but on the provider’s demonstrated ability to protect against repeat occurrences.

Consumer and Business Impact

The disruption to consumer services was broad. According to the independent outlet Meduza, Yandex’s main page was unavailable for a period, and Russian Railways’ website and mobile operator MegaFon also went down following the initial facility outage.

Yandex Go, the ride-hailing and delivery platform, experienced widespread interruption. Users in Moscow, Saint Petersburg, Yekaterinburg, Vladivostok, Krasnoyarsk, and Perm reported being unable to book vehicles, according to independent outlets Ostorozhno Novosti and Astra. Similar effects were documented in Serbia, Kazakhstan, Belarus, and Armenia, where Yandex operates as a significant mobility provider. In Rostov-on-Don, local dispatch operations reportedly ceased functioning, and drivers and couriers using the Yandex Pro application found themselves unable to log in. Internal customer support tooling was also affected, leaving staff unable to file error tickets.

Yandex Pay experienced payment interruptions, leaving users unable to complete purchases or access funds through the digital wallet. Dima Pirogov, head of Yandex’s fintech division, addressed users directly, writing that the division’s teams were restoring services step by step and that account records were intact. Yandex subsequently stated: “Records for each account are stored in multiple copies at different sites. We checked their integrity: not a single record was lost.” That statement reflects the underlying database architecture used across modern financial platforms – replicated, multi-site storage designed to preserve data integrity independently of the availability of any single site. The practical distinction is that the money and the records were safe, while the access layer that processes transactions and authenticates users was temporarily unavailable.

Other products were also affected, including the Alice voice assistant and connected smart home devices, and users reported problems with Yandex Music. The company stated that engineers were prioritising the most-used services and that access to Alice, Mail, Maps, Search, and Taxi was being progressively restored.

The impact extended to third-party businesses hosted on Yandex infrastructure. More than a dozen external services were affected, including retailers, internet service providers, an online psychotherapy service, and fitness businesses. The real estate platform Cian and the dating service Twinby reported outages, as did the fast-food chain Vkusno i Tochka, electronics retailer M.Video, and grocery chain Magnit. Alexander Savitsky, who operates a dating application with roughly 8,000 users, told Reuters that the service had been inaccessible since the disruptions began and that the principal risk was user attrition rather than data loss: “The main risk is losing users and their trust: people can’t use the app, and there’s no telling how many will return once service is restored.”

Corporate Response: Customer Migration, Contractual Changes, and Partner Arrangements

Yandex’s response has moved on three parallel tracks.

First, service restoration and workload redistribution. The company has stated that teams are working continuously to bring services back and to help affected customers, describing this as its top priority. Customers were advised to activate disaster-recovery plans and to reserve capacity in advance rather than depend solely on internal failover.

Second, third-party capacity arrangements. According to Russian state media reports, Yandex reached agreements with competing cloud providers – Selectel, K2Cloud, and VK Cloud – to help affected customers migrate their data and services more quickly. This is a practical measure: when a provider’s own footprint is degraded, facilitating migration to competitors preserves customer relationships and reduces the risk of permanent churn, even though it means accepting short-term revenue loss.

Third, contractual adjustments. Yandex updated its terms of service to exclude liability for failure to meet contractual obligations arising from incidents of this nature, a change that may limit customers’ ability to seek compensation for the disruption. Reuters described the attacks on the data centers as the most serious outage Russia’s digital infrastructure has experienced since the war began.

Institutional and Industry Response

The Russian government has acknowledged the severity of the situation. Digital Development Minister Maksut Shadayev told a State Duma committee that his ministry was working with the Defence Ministry on measures to improve the protection of data center facilities. “Yandex faced an unprecedented attack,” Shadayev said. “The Digital Development Ministry, together with the Defence Ministry, is working on the issue of protecting these facilities.” He did not specify what measures were under consideration, and noted that the scale of the events had been monitored in real time across the industry, with the wider sector assisting in the response.

Anton Gorelkin, First Deputy Chairman of the State Duma’s IT Committee, proposed a structural response: building toward a distributed architecture with more independent sites, stronger geographic separation, automatic load redistribution, and redundancy across communications, energy, and data. The recommendation is technically coherent and aligns with established practice in cloud resilience engineering. It is also expensive. Distributed architectures cost more to build and operate, introduce latency between sites, and take years rather than months to deliver. There is no rapid route to the resilience profile Gorelkin describes.

Yandex, for its part, has publicly framed the data centers as central to its operations – describing them as the “iron heart” of the company and acknowledged the practical effect on users. “Every outage means disrupted plans and an inability to do things that are part of everyday life or work,” the company said, adding that it was “very difficult to provide a timeline for restoring the equipment at the data centers.”

What This Reveals About Cloud Resilience Assumptions

Setting aside the specific circumstances, the episode offers several generalisable observations about how large-scale digital infrastructure behaves under correlated stress.

Redundancy assumes independence. Availability-zone architectures are designed around the assumption that failures occur independently. This assumption holds for hardware faults, software defects, and most operational errors. It does not hold for causes that affect multiple sites within a short window, whether those are geographic hazards, shared supply chain dependencies, or coordinated external events. Resilience planning that does not model correlated failure tends to overstate the protection actually available.

Capacity headroom is a business decision, not a technical constant. The amount of spare capacity maintained in a cloud platform is a commercial trade-off between resilience and cost. Holding enough headroom to absorb the loss of half the platform’s footprint would roughly double the capital and operating cost of the platform. The consequence is that beyond a certain point of simultaneous loss, degradation is arithmetically unavoidable.

Disaster recovery advisories reveal more than status pages. A cloud provider telling customers to invoke their own disaster recovery plans is a meaningful signal. It indicates that the provider’s internal mechanisms have reached their limits and that the responsibility for continuity has shifted to the customer’s own architecture which, for many organisations, is exactly where it should have been all along. The practical lesson for enterprises is that provider-side redundancy should be treated as a convenience, not as a substitute for an independent continuity plan that includes off-platform backups and tested migration paths.

Hardware scarcity changes recovery timelines. Yandex’s ability to restore service depends on procuring replacement equipment, particularly high-end accelerators. Where supply is constrained by export controls or market scarcity, recovery timelines extend from weeks to months, and the affected systems may not return to their prior configuration at all.

Concentration is the underlying variable. The common thread across consumer outages, enterprise cloud disruption, and AI capacity loss is concentration. Yandex operates the dominant search engine, the dominant ride-hailing platform, the dominant food delivery platform, a major payments system, and a major cloud platform in the same market – frequently running all of them on the same physical infrastructure. That integration delivers efficiency at normal times and transmits failure extremely effectively at abnormal ones. For regulators and enterprises alike, the episode is a reminder that efficiency and resilience are often in direct tension, and that the optimum point between them is a policy choice rather than a technical inevitability.

Outlook

Yandex has not published a restoration timeline for the affected facilities and has not disclosed the condition of the high-performance computing clusters at Sasovo and Vladimir. The company has stated that restoration work is ongoing and that affected customers should plan on the basis of alternatives rather than assuming a rapid return to prior capacity.

Three indicators will determine how this episode is ultimately assessed. The first is whether the affected cloud capacity is restored through repair or replaced through new construction, and over what timeframe. The second is customer retention on Yandex Cloud — specifically, how many of the 64,000 business customers invoked disaster-recovery plans and whether those plans led to permanent migration. The third is whether Yandex’s infrastructure strategy shifts toward greater geographic distribution, and how the cost of that shift is reflected in future pricing and capital expenditure.

For the wider technology industry, the episode is a useful case study regardless of geography. It demonstrates, with unusual clarity, the gap between designed redundancy and realised resilience — a gap that most organisations discover only when a correlated event tests both at once.