On Monday, June 22, 2026, a major network disruption tied to a reported fiber cut in eastern North America coincided with widespread access problems across X, Reddit, Discord, Zoom, Canva, Microsoft Teams, Robinhood, Fortnite, and other online services. Cloudflare said it did not see a global Cloudflare outage, instead pointing to Zayo network-route problems that could affect sites whether or not they used Cloudflare. The result was a familiar modern internet spectacle: one physical failure, one infrastructure provider’s routing pain, and millions of users watching unrelated services appear to fall over together. The story is not that “the internet went down.” It is that the internet’s supposed redundancy still has very visible pressure points.
For users, the distinction between a Cloudflare outage, a Zayo route failure, a fiber cut, and an app-specific brownout is academic. If X will not refresh, Teams calls stall, Reddit returns errors, and a bank or trading app refuses to load, the lived experience is simple: the internet is broken. That gap between engineering reality and user perception is where trust in modern infrastructure takes damage.
Cloudflare’s public line was careful. The company reportedly said it was not observing a global Cloudflare outage and identified Zayo, a network provider, as suffering an outage on some routes. At the same time, Cloudflare’s own status messaging referred to a fiber cut in eastern North America and warned of increased latency and timeouts for customers connecting through North America or accessing services in Europe.
That nuance matters. Cloudflare is not just a web host; it is an edge network, security layer, CDN, DNS provider, and routing intermediary for a huge portion of the web. Zayo is not a consumer brand; it is one of the companies whose fiber and transit services make the consumer-facing web possible. When either appears in an incident narrative, the public sees “Cloudflare down” because Cloudflare is the name most visible to website operators and technically minded users.
But this incident also shows why “Cloudflare caused it” may be too simple. Microsoft Teams, for example, does not fit neatly into the same bucket as a small website fronted by Cloudflare. When dozens of platforms degrade at once, the better reading is often that a shared network path, transit provider, route, or regional interconnection became unhealthy enough to expose the dependency map underneath.
Fiber cuts are not exotic. Network operators build around them with redundant paths, automatic rerouting, and traffic engineering. The problem is that redundancy is unevenly distributed. A hyperscaler may have multiple regional paths and private backbone capacity, while a smaller service may depend on a narrower mix of providers, CDN behavior, DNS, and transit agreements.
This is where the outage becomes more interesting than another round of status-page archaeology. A physical break in one geography reportedly affected users connecting across North America and Europe. That suggests the incident was not merely local in the consumer sense; it touched routes that mattered to globally used services. The internet is packet-switched, but it is not magic. Traffic has to go somewhere, and when the preferred somewhere disappears, the alternatives may be congested, suboptimal, or misconfigured.
The public internet has always been a federation of bargains: carriers, CDNs, cloud providers, exchanges, DNS operators, last-mile ISPs, and application owners all making routing decisions at different layers. Most days, the user experiences that complexity as speed. On outage days, the same complexity looks like chaos.
The company’s role is easy to misunderstand. Cloudflare can make websites faster, absorb attacks, proxy traffic, serve cached content, and steer users toward nearby edge locations. If its systems are impaired, the blast radius can be enormous. But if an underlying carrier route is broken, Cloudflare may also be one of the networks trying to work around somebody else’s failure while customers see Cloudflare-branded errors.
That distinction will not satisfy everyone. Site owners buy services like Cloudflare partly because they expect infrastructure complexity to be someone else’s problem. If a fiber cut elsewhere causes their site to become unreachable, they may reasonably ask whether the vendor’s routing, provider diversity, or regional failover was good enough.
Still, the blame game should not obscure the larger reality: Cloudflare is now part of the web’s shared nervous system. So are Microsoft, Amazon, Google, Akamai, Fastly, Zayo, Lumen, Cogent, Equinix, and a long list of less familiar operators. When one component has a bad hour, the effect can ripple through services that users believe are unrelated.
Downdetector is imperfect. It measures user reports, not root cause. A user may report Teams being down because their ISP is impaired, their DNS resolver is failing, or an enterprise VPN is misbehaving. During a large incident, popular services also attract more reports simply because more people try them.
But Downdetector has become the internet’s unofficial smoke alarm. It captures the moment when enough users notice enough failures at the same time to suspect a systemic event. That is useful, even if it is not forensic proof.
The uncomfortable part for operators is that user-report platforms often beat official communications. A status page may lag because engineers are still verifying scope, because incident communications are routed through internal approval, or because the company wants to avoid naming a vendor before it is sure. Users, meanwhile, are already comparing notes in real time.
A brief outage at 3 a.m. local time for a small service is an annoyance. A brief outage during the working day across collaboration tools, social platforms, design apps, trading services, and public-sector websites is a business event. It interrupts meetings, support queues, deployments, financial decisions, schoolwork, and emergency communications.
For WindowsForum readers, Microsoft Teams is the obvious example. Teams is not just chat software anymore; for many organizations it is the conference room, phone system, help desk channel, escalation bridge, and informal war room. When Teams is impaired during a broader internet event, IT staff can lose both the thing users complain about and the tool they use to coordinate the response.
That is the operational trap of cloud dependence. A company may have moved workloads to cloud platforms to avoid single points of failure in its own server room, only to centralize communications, identity, device management, documentation, and incident response in a different set of shared services. The resilience improved in one layer and quietly weakened in another.
A typical managed Windows environment now leans on cloud identity, Teams, SharePoint, OneDrive, Intune, Defender telemetry, browser-based line-of-business apps, SaaS admin portals, and remote support tools. Even when local machines are fine, users can become functionally stranded if the network path to those services degrades. The PC boots; the work does not.
The correct response is not nostalgia for on-prem everything. That ship has sailed for most organizations, and for good reasons. Cloud identity, endpoint management, and collaboration platforms solve real problems at scale. But resilience planning has to assume that the cloud control plane, the communications tool, or the network route to both may be impaired at the same time.
That means IT departments need out-of-band communications that are not merely another tab in the same browser session. It means documenting emergency access procedures somewhere reachable when SharePoint is not. It means knowing which apps fail closed, which fail open, and which fail in strange half-connected states that generate more tickets than clarity.
Attackers understand that panic compresses judgment. A fake “backup Teams login,” a bogus X mirror, a fraudulent Cloudflare status clone, or a malicious “connection repair” download can look plausible when the real service is failing. The more prominent the outage, the more convincing the bait becomes.
This risk is especially acute for crypto, trading, and business platforms. Robinhood appearing in outage lists is not just a consumer inconvenience; financial users may be more likely to click urgent-looking alternatives when they believe they are locked out during market movement. The same logic applies to wallet users, SaaS admins, and support teams under pressure.
Enterprises should treat major outages as phishing windows. Security teams often send warnings after a breach or campaign, but outage-driven fraud requires faster reflexes. The message can be simple: do not use mirror links, do not install “fix” tools, do not reauthenticate through third-party pages, and rely only on known status channels already bookmarked before the incident.
Two fiber paths in the same conduit are not truly diverse. Two transit providers using the same upstream dependency may fail together. Two cloud regions may still share identity, DNS, certificate, deployment, or management-plane dependencies. Two communication channels are not independent if both require the same SSO provider and the same impaired route.
That is why multi-cloud and multi-CDN strategies often disappoint when they are adopted as slogans rather than architectures. A company can add vendors and still preserve the same single point of failure in DNS, identity, monitoring, build pipelines, or human process. Resilience is not a shopping cart; it is a dependency exercise.
The Monday outage is a useful example because it appears to sit below the application layer. If your app servers were healthy but users could not reach the edge, did your redundancy help? If your CDN rerouted but your origin provider, DNS, or authentication layer was still reachable only through a degraded path, did your failover plan really exist?
For sysadmins, the practical question is not “Do we use Cloudflare?” or “Do we use Zayo?” It is “Which hidden dependencies would surprise us if they failed at 9:30 on a Monday morning?” The answer is usually longer than anyone wants.
Cloudflare’s distinction between not seeing a global outage and acknowledging a fiber cut was important. Yet for a customer experiencing timeouts, the distinction may have sounded evasive. A vendor can be technically correct and still fail to answer the operational question users actually have: “Is this you, is it the network, and what should we do right now?”
There is also a credibility problem when multiple status pages disagree by omission. One service says all systems operational while users report failures. Another blames a network provider. A third says it is monitoring recovery. A fourth says nothing. The fragmented truth reflects the fragmented architecture, but the user sees a fog machine.
The best incident communication now comes from companies that explain blast radius, user-visible symptoms, suspected dependencies, and recommended mitigations without overclaiming root cause. The worst comes from companies that treat status pages as liability shields. During a widespread outage, silence is not caution; it is an information vacuum someone else will fill.
The same providers now support memes, medical portals, video calls, design tools, software deployments, financial trades, and public services. A single network disruption can therefore look absurdly broad: X beside NHS England, Fortnite beside Teams, Reddit beside Robinhood. The list reads like a random sample of modern life because the underlying infrastructure is shared by design.
This is not necessarily a scandal. Shared infrastructure is why small companies can deliver global performance, why DDoS protection is accessible, and why users expect pages to load quickly from almost anywhere. The alternative is not a charmingly decentralized web where every site owns resilient global fiber. It is often a slower, less secure, more expensive web.
But the concentration trade-off deserves more honesty. We have optimized for scale, speed, and managed complexity. We have not always optimized for comprehensibility during failure. When the system works, abstraction is a feature. When the system fails, abstraction becomes the thing that prevents users and administrators from knowing where to look.
That opacity is a governance problem as much as an engineering one. Public agencies, hospitals, banks, schools, and enterprises increasingly depend on a small number of infrastructure layers without always understanding second-order exposure. Procurement may review security controls and compliance attestations, but it rarely models how a fiber cut in one region might affect access to a service used by staff in another.
Regulators sometimes approach this through cloud concentration risk, especially in finance and critical infrastructure. But the Monday incident shows the problem extends beyond cloud compute. CDNs, DNS, route optimization, identity, messaging, payment rails, and carrier transit all matter. The next meaningful outage may not come from a hyperscaler region; it may come from a provider whose name most customers never put on a risk register.
For enterprise IT, the answer is not to demand impossible transparency from every vendor. It is to build a local map of critical functions and the minimum dependencies required to keep them alive. If payroll, support, dispatch, clinical workflows, or incident response depend on a particular SaaS stack, administrators need to know how those systems behave when the normal path is impaired.
The June 22 outage will probably be remembered by most people as a brief afternoon when X froze, Teams stumbled, and half the web seemed unreliable. IT professionals should remember it differently: as another reminder that the modern internet is highly redundant in theory, selectively fragile in practice, and increasingly dependent on infrastructure companies whose failures become everyone’s failures. The next incident may involve a different provider, a different region, or a different protocol, but the preparation should start from the same premise: the cloud is physical, the dependencies are shared, and the safest organizations will be the ones that plan for both truths before the status page turns yellow.
The Internet Did Not Break, but Its Abstractions Did
For users, the distinction between a Cloudflare outage, a Zayo route failure, a fiber cut, and an app-specific brownout is academic. If X will not refresh, Teams calls stall, Reddit returns errors, and a bank or trading app refuses to load, the lived experience is simple: the internet is broken. That gap between engineering reality and user perception is where trust in modern infrastructure takes damage.Cloudflare’s public line was careful. The company reportedly said it was not observing a global Cloudflare outage and identified Zayo, a network provider, as suffering an outage on some routes. At the same time, Cloudflare’s own status messaging referred to a fiber cut in eastern North America and warned of increased latency and timeouts for customers connecting through North America or accessing services in Europe.
That nuance matters. Cloudflare is not just a web host; it is an edge network, security layer, CDN, DNS provider, and routing intermediary for a huge portion of the web. Zayo is not a consumer brand; it is one of the companies whose fiber and transit services make the consumer-facing web possible. When either appears in an incident narrative, the public sees “Cloudflare down” because Cloudflare is the name most visible to website operators and technically minded users.
But this incident also shows why “Cloudflare caused it” may be too simple. Microsoft Teams, for example, does not fit neatly into the same bucket as a small website fronted by Cloudflare. When dozens of platforms degrade at once, the better reading is often that a shared network path, transit provider, route, or regional interconnection became unhealthy enough to expose the dependency map underneath.
The Cloud Has a Street Address
The most striking part of the outage was not the list of affected websites. It was the alleged cause: damage to a physical internet cable in North America. For all the talk of serverless computing, global failover, anycast routing, and hyperscale resilience, a backhoe, storm, maintenance accident, or utility mishap can still turn the digital economy into a very analog repair job.Fiber cuts are not exotic. Network operators build around them with redundant paths, automatic rerouting, and traffic engineering. The problem is that redundancy is unevenly distributed. A hyperscaler may have multiple regional paths and private backbone capacity, while a smaller service may depend on a narrower mix of providers, CDN behavior, DNS, and transit agreements.
This is where the outage becomes more interesting than another round of status-page archaeology. A physical break in one geography reportedly affected users connecting across North America and Europe. That suggests the incident was not merely local in the consumer sense; it touched routes that mattered to globally used services. The internet is packet-switched, but it is not magic. Traffic has to go somewhere, and when the preferred somewhere disappears, the alternatives may be congested, suboptimal, or misconfigured.
The public internet has always been a federation of bargains: carriers, CDNs, cloud providers, exchanges, DNS operators, last-mile ISPs, and application owners all making routing decisions at different layers. Most days, the user experiences that complexity as speed. On outage days, the same complexity looks like chaos.
Cloudflare Became the Name on the Blame
Cloudflare sits in an awkward place during any widespread web incident. It is large enough that its problems feel like internet problems, but it is also upstream, downstream, or adjacent to many failures it does not directly cause. That makes it both a useful diagnostic signal and a convenient scapegoat.The company’s role is easy to misunderstand. Cloudflare can make websites faster, absorb attacks, proxy traffic, serve cached content, and steer users toward nearby edge locations. If its systems are impaired, the blast radius can be enormous. But if an underlying carrier route is broken, Cloudflare may also be one of the networks trying to work around somebody else’s failure while customers see Cloudflare-branded errors.
That distinction will not satisfy everyone. Site owners buy services like Cloudflare partly because they expect infrastructure complexity to be someone else’s problem. If a fiber cut elsewhere causes their site to become unreachable, they may reasonably ask whether the vendor’s routing, provider diversity, or regional failover was good enough.
Still, the blame game should not obscure the larger reality: Cloudflare is now part of the web’s shared nervous system. So are Microsoft, Amazon, Google, Akamai, Fastly, Zayo, Lumen, Cogent, Equinix, and a long list of less familiar operators. When one component has a bad hour, the effect can ripple through services that users believe are unrelated.
Downdetector Became the Public Status Page
The first visible sign for many users was not a Cloudflare status update or a carrier bulletin. It was a spike on Downdetector. Reports for X reportedly surged into the tens of thousands within minutes, while users also flagged problems with Reddit, Discord, Zoom, Canva, Microsoft Teams, Robinhood, Fortnite, and internet providers including Sky, EE, and Three.Downdetector is imperfect. It measures user reports, not root cause. A user may report Teams being down because their ISP is impaired, their DNS resolver is failing, or an enterprise VPN is misbehaving. During a large incident, popular services also attract more reports simply because more people try them.
But Downdetector has become the internet’s unofficial smoke alarm. It captures the moment when enough users notice enough failures at the same time to suspect a systemic event. That is useful, even if it is not forensic proof.
The uncomfortable part for operators is that user-report platforms often beat official communications. A status page may lag because engineers are still verifying scope, because incident communications are routed through internal approval, or because the company wants to avoid naming a vendor before it is sure. Users, meanwhile, are already comparing notes in real time.
The Outage Was Short, but the Lesson Was Not
Many reports suggested the worst of the disruption eased within less than an hour for major services. That is operationally impressive if true. It also does not make the outage trivial.A brief outage at 3 a.m. local time for a small service is an annoyance. A brief outage during the working day across collaboration tools, social platforms, design apps, trading services, and public-sector websites is a business event. It interrupts meetings, support queues, deployments, financial decisions, schoolwork, and emergency communications.
For WindowsForum readers, Microsoft Teams is the obvious example. Teams is not just chat software anymore; for many organizations it is the conference room, phone system, help desk channel, escalation bridge, and informal war room. When Teams is impaired during a broader internet event, IT staff can lose both the thing users complain about and the tool they use to coordinate the response.
That is the operational trap of cloud dependence. A company may have moved workloads to cloud platforms to avoid single points of failure in its own server room, only to centralize communications, identity, device management, documentation, and incident response in a different set of shared services. The resilience improved in one layer and quietly weakened in another.
Windows Shops Should Read This as an Identity and Communications Drill
The outage was not a Windows outage. It was not an Azure outage in the simple sense. But Windows-heavy organizations should still treat it as a warning about how much of the modern desktop depends on external reachability.A typical managed Windows environment now leans on cloud identity, Teams, SharePoint, OneDrive, Intune, Defender telemetry, browser-based line-of-business apps, SaaS admin portals, and remote support tools. Even when local machines are fine, users can become functionally stranded if the network path to those services degrades. The PC boots; the work does not.
The correct response is not nostalgia for on-prem everything. That ship has sailed for most organizations, and for good reasons. Cloud identity, endpoint management, and collaboration platforms solve real problems at scale. But resilience planning has to assume that the cloud control plane, the communications tool, or the network route to both may be impaired at the same time.
That means IT departments need out-of-band communications that are not merely another tab in the same browser session. It means documenting emergency access procedures somewhere reachable when SharePoint is not. It means knowing which apps fail closed, which fail open, and which fail in strange half-connected states that generate more tickets than clarity.
The Security Risk Arrives After the Error Page
One of the sharper warnings after the outage came from security observers who noted that outages create fertile ground for phishing. That is not theoretical. When users cannot reach a familiar service, they search for status updates, mirrors, alternate login pages, cached links, VPN workarounds, and social media posts claiming to explain the fix.Attackers understand that panic compresses judgment. A fake “backup Teams login,” a bogus X mirror, a fraudulent Cloudflare status clone, or a malicious “connection repair” download can look plausible when the real service is failing. The more prominent the outage, the more convincing the bait becomes.
This risk is especially acute for crypto, trading, and business platforms. Robinhood appearing in outage lists is not just a consumer inconvenience; financial users may be more likely to click urgent-looking alternatives when they believe they are locked out during market movement. The same logic applies to wallet users, SaaS admins, and support teams under pressure.
Enterprises should treat major outages as phishing windows. Security teams often send warnings after a breach or campaign, but outage-driven fraud requires faster reflexes. The message can be simple: do not use mirror links, do not install “fix” tools, do not reauthenticate through third-party pages, and rely only on known status channels already bookmarked before the incident.
Redundancy Is Not the Same as Independence
The internet industry likes to talk about redundancy as if it were a binary property. Either you have it or you do not. In reality, redundancy has quality, diversity, and failure-mode assumptions.Two fiber paths in the same conduit are not truly diverse. Two transit providers using the same upstream dependency may fail together. Two cloud regions may still share identity, DNS, certificate, deployment, or management-plane dependencies. Two communication channels are not independent if both require the same SSO provider and the same impaired route.
That is why multi-cloud and multi-CDN strategies often disappoint when they are adopted as slogans rather than architectures. A company can add vendors and still preserve the same single point of failure in DNS, identity, monitoring, build pipelines, or human process. Resilience is not a shopping cart; it is a dependency exercise.
The Monday outage is a useful example because it appears to sit below the application layer. If your app servers were healthy but users could not reach the edge, did your redundancy help? If your CDN rerouted but your origin provider, DNS, or authentication layer was still reachable only through a degraded path, did your failover plan really exist?
For sysadmins, the practical question is not “Do we use Cloudflare?” or “Do we use Zayo?” It is “Which hidden dependencies would surprise us if they failed at 9:30 on a Monday morning?” The answer is usually longer than anyone wants.
Status Pages Still Speak Like Lawyers
Incident communications have improved over the past decade, but they remain oddly unsatisfying during cross-internet failures. Status pages often say “investigating,” “identified,” “monitoring,” and “resolved” while users are still trying to understand whether they should cancel meetings, pause deployments, reroute support, or call a carrier. The language is accurate, but thin.Cloudflare’s distinction between not seeing a global outage and acknowledging a fiber cut was important. Yet for a customer experiencing timeouts, the distinction may have sounded evasive. A vendor can be technically correct and still fail to answer the operational question users actually have: “Is this you, is it the network, and what should we do right now?”
There is also a credibility problem when multiple status pages disagree by omission. One service says all systems operational while users report failures. Another blames a network provider. A third says it is monitoring recovery. A fourth says nothing. The fragmented truth reflects the fragmented architecture, but the user sees a fog machine.
The best incident communication now comes from companies that explain blast radius, user-visible symptoms, suspected dependencies, and recommended mitigations without overclaiming root cause. The worst comes from companies that treat status pages as liability shields. During a widespread outage, silence is not caution; it is an information vacuum someone else will fill.
The Consumer Internet and Enterprise Internet Are the Same Internet Now
There was a time when consumer web outages and enterprise IT outages felt like separate categories. Social media could break while corporate systems kept humming, or an enterprise VPN could fail while public websites worked fine. That separation has eroded.The same providers now support memes, medical portals, video calls, design tools, software deployments, financial trades, and public services. A single network disruption can therefore look absurdly broad: X beside NHS England, Fortnite beside Teams, Reddit beside Robinhood. The list reads like a random sample of modern life because the underlying infrastructure is shared by design.
This is not necessarily a scandal. Shared infrastructure is why small companies can deliver global performance, why DDoS protection is accessible, and why users expect pages to load quickly from almost anywhere. The alternative is not a charmingly decentralized web where every site owns resilient global fiber. It is often a slower, less secure, more expensive web.
But the concentration trade-off deserves more honesty. We have optimized for scale, speed, and managed complexity. We have not always optimized for comprehensibility during failure. When the system works, abstraction is a feature. When the system fails, abstraction becomes the thing that prevents users and administrators from knowing where to look.
The Real Outage Was a Dependency Map Nobody Gets to See
Every major incident briefly reveals the shape of the internet, but only in silhouette. Users see which services fail together. Operators see their own dashboards. Vendors see their segment of the path. Almost nobody sees the full dependency graph.That opacity is a governance problem as much as an engineering one. Public agencies, hospitals, banks, schools, and enterprises increasingly depend on a small number of infrastructure layers without always understanding second-order exposure. Procurement may review security controls and compliance attestations, but it rarely models how a fiber cut in one region might affect access to a service used by staff in another.
Regulators sometimes approach this through cloud concentration risk, especially in finance and critical infrastructure. But the Monday incident shows the problem extends beyond cloud compute. CDNs, DNS, route optimization, identity, messaging, payment rails, and carrier transit all matter. The next meaningful outage may not come from a hyperscaler region; it may come from a provider whose name most customers never put on a risk register.
For enterprise IT, the answer is not to demand impossible transparency from every vendor. It is to build a local map of critical functions and the minimum dependencies required to keep them alive. If payroll, support, dispatch, clinical workflows, or incident response depend on a particular SaaS stack, administrators need to know how those systems behave when the normal path is impaired.
The Monday Failure Leaves a Practical Paper Trail
The incident’s public details will likely be refined as providers publish or quietly update postmortems. The broad contours, however, are already useful for anyone responsible for keeping Windows endpoints, SaaS access, and business communications running through the next outage.- Organizations should assume that collaboration platforms may be unavailable during the exact window when staff need them for incident response.
- Administrators should maintain at least one out-of-band communication method that does not depend on the same identity, DNS, SaaS, or network path as the primary toolset.
- Security teams should warn users that major outages are prime moments for phishing pages, fake mirrors, malicious downloads, and fraudulent status updates.
- Service owners should test whether their redundancy depends on genuinely diverse providers and routes, not merely multiple products with overlapping infrastructure.
- Help desks should prepare short outage scripts that distinguish local device problems from upstream service degradation, because users will otherwise reinstall apps, reset passwords, and create noise.
- Executives should understand that a short internet infrastructure outage can still be a material business disruption if it hits communications, customer access, trading, or public-service delivery.
The June 22 outage will probably be remembered by most people as a brief afternoon when X froze, Teams stumbled, and half the web seemed unreliable. IT professionals should remember it differently: as another reminder that the modern internet is highly redundant in theory, selectively fragile in practice, and increasingly dependent on infrastructure companies whose failures become everyone’s failures. The next incident may involve a different provider, a different region, or a different protocol, but the preparation should start from the same premise: the cloud is physical, the dependencies are shared, and the safest organizations will be the ones that plan for both truths before the status page turns yellow.
References
- Primary source: metro.co.uk
Published: 2026-06-22T14:42:16.390607
Parts of the internet go down after major network outage | News Tech | Metro News
Parts of the internet go down after major network outage
metro.co.uk
- Related coverage: geo.tv
X (formerly Twitter), Zoom, Reddit, Teams all go down at once: Reason revealed
X , Zoom, Reddit, and Microsoft Teams suffered a major outage on Monday morning, June 22. The outage left thousands of users unable to access their social media platforms and workplace communication tools. Users began reporting...www.geo.tv - Related coverage: ad-hoc-news.de
Internet-Störung: 36.000 Ausfallmeldungen bei X in 15 Minuten
Ein Glasfaserschaden bei Zayo verursachte zeitgleiche Ausfälle von X, Teams und Zoom. Cloudflare behob die Störung nach 20 Minuten.www.ad-hoc-news.de - Related coverage: harianbasis.co
Cloudflare Network Disruption Triggers Widespread Internet Outages
A massive Cloudflare network outage on Monday disrupted major websites globally, including X and Reddit, following an earlier AWS infrastructure failure.www.harianbasis.co - Related coverage: cyberkendra.com
X, Reddit, and Zoom Down Globally Due to Zayo Network Outage - Cyber Kendra
X, Reddit, and Zoom went dark on June 22 as Zayo network routes failed — 35,000+ global reports, including 1,800+ from India.www.cyberkendra.com - Related coverage: asatunews.co.id
Cloudflare Network Disruption Affects Major Websites Globally
A massive Cloudflare network outage triggered by a fiber cut in North America caused disruptions for millions of users across platforms like X and Reddit.www.asatunews.co.id
- Related coverage: outage.now
Zoom down? Current status and outage map
See if Zoom is down or it's just you. Check current status and outage map. Post yours and see other's reports and complaints
outage.now
- Related coverage: radar.cloudflare.com
Outage Center | Cloudflare Radar
Explore the latest Internet traffic anomalies and verified outages.radar.cloudflare.com - Related coverage: membernovasupport.com
[Resolved] MemberNova Portal Outage – Cloudflare Service Disruption - News / Service Issues - MemberNova Support
PDF documentwww.membernovasupport.com
- Related coverage: techxplore.com