Yandex Cloud Cascade Failure October 2026 Exposes Multi-AZ Limits and Capacity Exhaustion Risks
In October 2026, Yandex Cloud experienced a major cascade failure spanning data centers in Sasovo, Kaluga, and Vladimir, demonstrating the physical limits of Multi-AZ resilience when multiple zones suffer simultaneous outages.
The events began on 8 October at 01:31 MSK in zone ru-central1-b (incident 2092) with power disruptions. By 15:19 MSK, Yandex Cloud confirmed a fire caused by a drone attack that completely halted the Sasovo facility. Clients were advised to migrate workloads, yet new virtual machines, Managed Kubernetes clusters, and databases could not be created in remaining zones due to emerging capacity constraints.
At 15:30 MSK the same day, an unrelated configuration error during planned maintenance in the Curator DDoS protection service degraded access for 34 minutes to major Russian media and fintech platforms including RBK, Kommersant, Vedomosti, Interfax, T-Bank, and Avito.
On 9 October, damage was reported at the Kaluga site. Yandex Cloud arranged emergency resource placement with external providers Selectel, K2Cloud, and VK Cloud. Control Plane components for regional Kubernetes clusters could only be moved out of the affected zone after approximately 36 hours.
By 10 October, quota allocation shifted to fully manual mode, freezing automatic scaling and giving priority to critical workloads. On 11 October at 04:00 MSK, power failures struck zone ru-central1-a (incident 2136) in Vladimir, leading to another full site shutdown and an official warning that remaining capacity no longer guaranteed availability.
At 07:13 MSK on 11 October, compute resources remained available only in zones ru-central1-d and ru-central1-e. Many database clusters switched to read-only or became unavailable, while object storage allowed reads but not writes. Several Kubernetes clusters lost manageability because their control planes resided in failed zones.
Services such as Yandex Go, Yandex Eda, Yandex Pay, and Yandex 360 were impacted, along with the state VetIS system. The SaaS platform Salebot lost access to client projects and weekly backups, forcing a rollback to 4 October data and requiring more than 24 hours to rebuild indexes after restoring only six of 40 servers.
The outage illustrated that Multi-AZ architectures fail when surviving zones lack sufficient physical capacity, a condition known as Capacity Exhaustion. Additional risks included Control Plane dependency, manual quota limits blocking automated recovery, and simultaneous demand from multiple customers overwhelming alternative providers.
To mitigate such risks, the analysis recommends separating ingress buffers from primary backends. A lightweight FastAPI service deployed on an independent VDS can accept webhooks, validate tokens via constant-time comparison, and durably append events to a local JSONL queue using fsync before returning 200 OK responses.
Related articles
AmneziaWG Container for MikroTik Routers Delivers Top Performance Six Months After Launch
A developer released an AmneziaWG container for MikroTik devices in February 2026 and has since added major improvements in speed, protocol support, and stability. The lightweight container leverages the router's native WireGuard implementation for cryptography while handling AmneziaWG obfuscation in software. Performance now reaches 250-350 Mbit/s on models such as Hap Ax3 and RB5009B after switching to C code and increasing buffer sizes with RouterOS 7.24. New features include server mode for connecting multiple MikroTik devices, random port hopping, IPv6 support, dynamic DNS, and offline configuration. The project survived an early GitHub ban caused by test scripts and has grown to over 370 stars while remaining fully offline and privacy-focused.
Building Resilient DoH Failover on MikroTik RouterOS to Handle Unreachable Cloudflare Responses
A network administrator encountered a persistent issue in a branch office where pages like Tailwind CSS CDN failed to load despite valid DNS responses from Cloudflare DoH. The problem stemmed from unreachable IP addresses such as 8.6.112.0 and 8.47.69.0 returned by the resolver, which RouterOS treated as healthy because it only checked for valid IP types rather than route reachability. RouterOS supports only a single active DoH upstream via the use-doh-server parameter, requiring custom scripting for failover between multiple endpoints like Cloudflare and dns.google. The solution involved static DNS entries for bootstrap addresses, certificate trust anchors including SSL.com TLS ECC Root CA 2022, and a health monitor script that probes using DNS-JSON API calls instead of switching the resolver directly. Multiple iterations addressed issues like cache-based false positives, plain DNS fallback risks from provider spoofing, and clock validation to prevent certificate failures. The final implementation uses thresholds for failure and recovery to avoid flapping and ensures post-switch verification before committing to a backup endpoint.
NetRuleRouter Alpha Released to Route Traffic Across Multiple Connections Without Disabling VPN
Developer krox1 has released the first public alpha of NetRuleRouter v0.1.0-alpha.1 for Windows and Linux, a local network policy manager that distributes traffic between primary and secondary connections based on domains, IP ranges, applications, and subnets. The tool emerged from practical issues that intensified after Russian authorities discussed VPN restrictions in March 2026, with operators and platforms later prompting users to disable VPN for domestic services. NetRuleRouter sits on top of existing connections rather than acting as a VPN client or proxy, allowing users to keep corporate VPNs, personal VPNs, and direct internet active simultaneously. It supports seven matching methods including exact domains, wildcard subdomains, CIDR ranges, and application paths, with priority rules to resolve overlaps and built-in leak protection that prevents protected destinations from falling back when the secondary connection drops. The alpha includes diagnostic tracing, preset rule sets for Russia and other regions, import/export capabilities, and a first-run wizard that configures the background service and initial bindings. Limitations around DNS, shared IPs, and brief startup windows are documented, and the project explicitly does not protect against account-level blocks by services such as Anthropic.
Setting Up Nextcloud Talk on TrueNAS with Custom Domain for Private Family Calls
A detailed guide explains how to deploy Nextcloud Talk on a TrueNAS server behind a custom domain to create a self-hosted messaging and calling platform for family use. The author addresses problems with commercial messengers such as VK notifications failing on iOS and Telegram requiring VPN connections. The solution uses HestiaCP on a VPS for reverse proxying, Let's Encrypt SSL certificates, and port forwarding on a home router to reach the TrueNAS instance at 192.168.0.17:30027. Additional steps cover configuring coturn for TURN relay to enable reliable voice and video calls, updating trusted domains in Nextcloud, and disabling router DoS protection. The setup also enables Screen Sharing, reactions, and push notifications while keeping all data under user control.