← All articles

A Fiber Cut on Zayo's Network Took Down X, Reddit, Zoom, and More on June 22

A routing failure at backbone provider Zayo knocked out X, Reddit, Zoom, Discord, and dozens more platforms on June 22, 2026. Here is what happened and what IT teams should do about it.

On Monday morning, June 22, 2026, tens of thousands of users worldwide found their feeds frozen, their video calls dead, and their favorite platforms returning nothing but errors. The culprit was not a hyperscaler cloud failure, not a cyberattack, and not a bug in any of the platforms people blamed out loud. It was a routing failure at Zayo, a Tier 1 internet backbone provider that most business users have never heard of but depend on every single day.

What Happened

According to Downdetector, service issues began shortly after 2:30 p.m. UK time on June 22, with reports spiking across all affected services just before 3 p.m. In the United States, where the disruption hit hardest during the morning, nearly 36,000 users reported issues with X between 9:45 a.m. and 10 a.m. ET, one of the platform's sharpest complaint spikes in recent months. Users reported frozen timelines, feeds that refused to refresh, and an app that would not load at all. By 10:26 a.m., reports had fallen to just over 2,000 as service gradually returned.

Among the most widely affected platforms were Discord, Reddit, Canva, Zoom, Fortnite, Robinhood, Microsoft Teams, and X. The disruption was global, with affected users confirmed in the United States, Greece, the United Kingdom, France, and Algeria. India was hit particularly hard during peak evening hours, with reports climbing to roughly 1,800 around 9:45 p.m. IST as users found themselves unable to refresh timelines, run searches, or access real-time updates.

The root cause, once identified, pointed not at the big-name platforms but at the infrastructure beneath them. The primary issue stemmed from a fiber cut affecting network connectivity in Eastern North America. Websites that relied exclusively on Zayo for their network routing became temporarily unreachable.

Zayo is a major transit network provider, one of the invisible highways that carries internet traffic between data centers and end users. When a route-level failure hits a provider like Zayo, any platform depending on those specific network paths loses reachability, regardless of how robust its own servers are.

Who Said What

Cloudflare was quick to clarify its own position. A Cloudflare spokesperson told Newsweek: "Cloudflare is not currently experiencing a global outage. The only issue we're aware of is that Zayo, a network provider, is experiencing an outage on some of its network routes. That may cause some sites using Zayo exclusively to be unreachable, whether they use Cloudflare or not."

Cloudflare itself was experiencing increased error rates as of 10:20 a.m. ET, which was initially flagged as a potential cause given that X and Reddit both use it for cloud-based content delivery. But by the time Cloudflare issued its statement, the blame had been placed firmly upstream. Cloudflare noted that evidence pointed to recovery efforts already underway and expected the disruption to be short-lived. X appeared to recover within about 45 minutes. Zayo did not issue a public statement widely distributed to the press.

Why This Matters for Enterprise IT Teams

Most IT operations teams have playbooks for when AWS, Azure, or Google Cloud goes down. Far fewer have mapped out what happens when a Tier 1 transit carrier like Zayo takes a hit and silently makes half their SaaS tools unreachable.

This was less a clean "one company broke the internet" story than a reminder that modern online life rests on a stack of cloud, transit, DNS, edge, authentication, and status-page dependencies most users never see. The public symptom was simple: apps were slow, inaccessible, or throwing errors. The infrastructure lesson is more uncomfortable. Even when the cloud is not technically down, the internet can still feel completely broken.

For businesses that rely on Zoom for customer calls, Teams for internal communication, or Discord for operations, a 45-minute outage in the middle of a workday is a real problem. Organizations should not rely on one SaaS channel for incident communication, especially when that channel may be caught in the same outage. That is an easy lesson to ignore right up until the moment your incident-response Slack channel goes dark at the same time as the incident itself.

There is also a monitoring blind spot worth addressing. An application server can be perfectly healthy, a cloud region fully operational, and a CDN reporting all-green, yet users on specific network paths can still be completely locked out. Vendor dashboards do not always reflect every user-visible path failure.

Concrete Steps to Take Now

1. Map your transit dependencies. Work with your ISP and CDN vendors to understand which Tier 1 backbone providers carry your traffic. Zayo, Lumen, Cogent, NTT, and Tata Communications are names that rarely appear in your contracts but frequently determine whether your users can reach your services.

2. Run multi-path redundancy where it counts. Spreading cloud services and routing traffic through multiple regions allows users to maintain at least minimal functionality during a major transit failure. If your architecture relies on a single network provider for all routes, a single fiber cut can replicate exactly what happened on June 22.

3. Build a backup communication channel now, not during an incident. If Teams and Zoom are both affected in an outage, you need a pre-agreed fallback: a phone bridge number, an SMS group, or a secondary platform on a different network path. Decide this in advance and test it at least once per quarter.

4. Set up external synthetic monitoring. Use tools that probe your services from multiple geographic vantage points across separate network providers. Internal monitoring tells you your servers are healthy. External monitoring tells you whether your users can actually reach them. You need both.

5. Review your SLA assumptions. Resilience planning should cover DNS, identity, CDN, transit, observability, and communications dependencies, not just application servers and cloud regions. Most SLAs from cloud vendors cover their own infrastructure, not the full path from user to application.

The Bigger Picture

June 22 was another public rehearsal for a larger truth: the internet's most important failures are no longer single crashes but shared dependencies revealing themselves all at once. Platforms that look completely independent at the application layer often share underlying transit providers, CDN nodes, or DNS resolvers. When one of those shared layers breaks, the failure looks chaotic and widespread precisely because the connections are invisible.

This is not a new problem, but it is a growing one. As enterprises run more of their operations on SaaS platforms, the dependency graph underneath those platforms grows longer and less visible. A fiber cut in Eastern North America should not be able to simultaneously freeze communications tools, collaboration platforms, gaming networks, fintech apps, and design software used by teams on five continents. On June 22, 2026, it did.

How 247techify can help

At 247techify, we help businesses map their real IT dependencies, build resilient infrastructure architectures, and put monitoring in place that catches problems at the network edge before users do. If Monday's outage revealed gaps in your own continuity or visibility plans, we would be glad to talk through your specific setup. Reach us at https://www.247techify.com/ and let us help you get ahead of the next one.