Three Data Centers, Four Days: What the Yandex Outage Teaches Us About the Internet's Physical Layer

On the morning of October 11, 2026, Yandex Cloud customers woke up to a status page written in the language of disaster recovery. One of Russia's biggest data centers, in Vladimir, had been "completely suspended." The platform was running in "emergency" mode. The remaining configuration was "unstable," and customers should activate disaster recovery plans on any other infrastructure they could find. Technical support channels, the company warned, might themselves go down.

It was the third such message in four days. A facility in Sasovo had burned on October 8. The Kaluga campus, Yandex's largest, had been partially knocked out on October 9. By the time Vladimir went dark, three of Yandex's five main data centers were offline or degraded, and more than 80 services, from cloud computing and databases to music, taxis, and payments, were in trouble. Tom's Hardware counted 84 services down on the company's own status page.

One company, one country, one giant single point of failure

Yandex is often called Russia's Google, and the comparison understates how much of the country's digital life runs through one company's servers. Search, maps, navigation, ride hailing, delivery, music, email, cloud storage, and the cloud platform that hosts thousands of other businesses, including banks, transport apps, and Russian Railways, all draw on the same physical footprint. When three data centers failed, the symptoms spilled across borders: Euronews reported broken taxi ordering in Russian cities and login and navigation problems in Serbia, Kazakhstan, Belarus, and Armenia.

Cloudflare Radar, which watches global traffic patterns, registered the collapse in numbers. Traffic from Yandex's autonomous system (AS13238) fell off a cliff, with bot requests dropping to 0.4 percent of the two-week maximum. NetBlocks measured Yandex Cloud traffic at roughly 30 percent of normal. An entire national cloud, visible in the telemetry, going dim.

The internet is supposed to route around damage. That is its founding promise. So why did it not this time?

Why redundancy did not save them

Modern cloud infrastructure is built on a simple idea: never put everything in one building. Data centers are organized into zones and regions, and customers are told to spread their workloads across them so that no single failure takes everything down. Yandex offered the same model. The ru-central1-a availability zone lived at the Vladimir site, and the October 11 outage notice appeared there around 4:00 a.m. local time.

Redundancy works against random failures. A power outage, a cooling fault, a software bug: these are uncorrelated, and spreading load across buildings survives them. It fails differently against correlated shocks, where the same cause hits multiple buildings at once. Four days, three facilities, one campaign of drone strikes that Yandex itself confirmed, is a textbook correlated shock. There is no availability zone in the design that assumes someone will attack three of your five sites in 96 hours.

And the losses compounded in a way that made failover impossible. The Sasovo facility reportedly held two of the three supercomputers Yandex uses to develop its AI models; after the fire, the company said it could not confirm whether the equipment there would ever run again. You cannot fail over to a building that has burned. Kaluga lost several entire modules, according to the company, at a campus designed for 63 megawatts and more than 3,800 racks. By the time Vladimir's 50-megawatt site shut down, the surviving capacity was a fraction of what the cloud needed, and Yandex told its own customers the remaining configuration was unstable.

Redundancy works against random failures. It fails differently against correlated shocks, where the same cause hits three buildings in 96 hours.

The physical layer is the internet's real single point of failure

Every few weeks, a different piece of the internet's physical layer makes the news. Submarine cables get cut by anchors, as the Philippines-Singapore outage earlier this month showed. Buildings flood, burn, or get struck. And each time, the abstraction collapses: the cloud is not weather, it is concrete, steel, cooling towers, and substations, and all of it sits somewhere a disaster can reach.

Data centers concentrate risk by design. A 63-megawatt campus is efficient precisely because it puts enormous computing power under one roof, with one power feed architecture, one cooling system, one security perimeter. That efficiency is also the vulnerability. The internet's core protocols, BGP routing, DNS, anycast, are magnificent at rerouting around failures, but they cannot conjure capacity that no longer exists. When the buildings go, the packets have nowhere to go.

Notice what did not fail: the rest of the internet. Traffic destined for Yandex's customers that could be rerouted was rerouted. The global system did what it was built to do. The catastrophe was local, a national cloud losing most of its capacity at once, which is exactly the scale at which redundancy plans stop being theory and start being arithmetic. Eighty-plus services cannot be absorbed by two remaining sites designed for normal load, not emergency load.

What everyone else should take away

Yandex's situation is extreme, but the pattern is not. Every cloud customer everywhere is betting that their provider's failures will stay random and local. The Yandex outage is what happens when that bet loses: when the failure is deliberate, repeated, and aimed at the physical plant.

The lesson is boring and practical, which is why it will mostly be ignored. Spread critical workloads across providers, not just zones, because a single provider's entire geography can become one failure domain. Test disaster recovery plans before you need them; Yandex had to recommend them to customers mid crisis. And design for degraded operation: the services that survive are the ones that can run, slowly and partially, on a fraction of their normal capacity, not the ones that assume the full cloud will always be there.

As of October 12, 2026, Yandex has not given a restoration timeline for Sasovo or Vladimir, and its status page still describes operations as emergency mode. The buildings will be rebuilt, or they will not. Either way, the internet just got a fresh reminder of its oldest truth: it is made of things you can touch, and things you can touch can be broken.

References

BleepingComputer, Yandex confirms service outage as users lose access to cloud files, October 2026. NeoTeo, Yandex outage: What the two 0.4% figures measure, October 12, 2026. Al Jazeera reporting on the Vladimir strike, October 2026. WebProNews, Drone Strikes Silence Yandex Bot Traffic, October 2026. Softonic, Yandex loses a third data center in four days, October 12, 2026. Unbiased Headlines, Yandex Says Vladimir Data Center Is Completely Shut Down, October 11, 2026.