Cloudflare said on Monday, June 22, 2026, that it was investigating network problems tied to a fiber cut in Eastern North America, after users across North America reported timeouts, slow-loading sites, and errors across major apps and web services. The answer to “is Cloudflare down today?” is therefore more precise than the panic suggested: Cloudflare was not simply offline, but part of its network path was degraded badly enough to make the internet feel broken. The more uncomfortable story is that a localized infrastructure failure can now masquerade as a global web crisis. For Windows users, sysadmins, and IT teams, the incident is less a one-off outage than another audit of how much everyday computing depends on invisible traffic brokers.
The first wave of complaints reportedly accelerated shortly after 9:30 a.m. Eastern time, with Downdetector showing spikes not only for Cloudflare but also for AWS and a long list of consumer and workplace services. That pattern is familiar now: users do not experience the internet as a stack of providers, transit routes, caches, authentication gateways, DNS resolvers, and application backends. They experience it as “Teams is broken,” “Reddit will not load,” or “my browser is timing out.”
Cloudflare’s own explanation pointed to increased error rates and latency, then to a fiber cut in Eastern North America. That matters because it suggests a physical network event rather than a code deployment, platform bug, or cyberattack. But for the end user, the distinction was mostly academic during the outage window. If a login request fails, a social feed freezes, or a SaaS dashboard spins forever, the failure mode looks the same.
The incident also collided with the most sensitive part of the workday. Morning outages in the U.S. hit authentication, chat, meetings, dashboards, order systems, and monitoring workflows just as businesses are coming online. A few minutes of degraded traffic can trigger an outsized response because everyone is trying to answer the same question at once: is this our network, our vendor, our cloud region, or the public internet?
That uncertainty is why Cloudflare incidents feel larger than their formal blast radius. The company sits in front of websites, APIs, identity flows, zero-trust access products, DNS services, and security controls. When those paths slow or fail, the symptoms scatter across brands that may not seem related to one another.
That distinction matters because outage dashboards are often treated like forensic tools when they are really public smoke alarms. A spike tells us that a meaningful number of people experienced trouble at roughly the same time. It does not, by itself, tell us whether the culprit was Cloudflare, AWS, a transit provider, a regional carrier issue, a service-specific bug, or a chain reaction among several of them.
Still, smoke alarms are not useless just because they are imprecise. In incidents like Monday’s, Downdetector often becomes the fastest shared vocabulary for users and help desks. If your company’s monitoring is green but employees cannot reach third-party services, a public surge of complaints can help separate local misconfiguration from a broader event.
The danger is that public dashboards can amplify confusion. A major platform may show a spike because its own service is down, because its users traverse a degraded path, or because people see other outage reports and test the service at unusual volume. Outage reporting is both telemetry and crowd behavior.
That does not mean AWS complaints were imaginary. Users may have been unable to reach AWS-hosted applications through degraded routes, or some services may have had their own parallel trouble. It does mean that lumping AWS and Cloudflare together as a single outage risks flattening the incident into a generic “the cloud is down” story.
For IT teams, that difference is operationally important. If AWS control planes are failing, the mitigation playbook looks one way. If a CDN, DNS, security edge, or transit route is impaired, the playbook looks different. The correct response may involve bypass rules, alternate endpoints, failover routing, status messaging, or simply waiting for upstream recovery.
The broader lesson is that public cloud and internet edge providers are now so intertwined that users perceive them as one dependency. The web’s architecture is distributed, but its failure experience is often centralized.
That makes edge-provider outages unusually disruptive. A database outage may break one application. An identity outage may block a class of users. An edge outage can make many unrelated services appear unreachable, slow, or unreliable because it sits at the front door.
This is the bargain many organizations have knowingly accepted. Cloudflare and similar providers offer global scale, attack absorption, performance gains, simpler certificate management, and a practical way for smaller teams to operate with infrastructure sophistication they could never build alone. The tradeoff is concentration risk.
There is no serious return to a romantic old internet where every business runs its own globally resilient network. The economics do not work, and the security burden would be worse for most organizations. The real question is whether businesses understand where their dependencies are concentrated and whether their continuity plans reflect that reality.
The cloud industry sells redundancy, and often delivers it. But redundancy is not the same as infinite independence. Providers may have multiple routes that share physical corridors, depend on common carriers, or converge at the same exchange points. A single cut should not take down the internet, but it can degrade enough high-value paths to make millions of users notice.
This is why “localized” incidents can feel global. If the affected region sits between dense user populations and major application hosting footprints, the problem is not geographically contained in the way a weather map might imply. Traffic that begins in North America and targets services in Europe, or vice versa, can cross exactly the kind of path where a regional fiber event becomes a transatlantic performance problem.
For WindowsForum readers, this is the piece worth lingering on. Your laptop, browser, Teams client, VPN agent, and endpoint security stack may all be healthy while the path between them and the service they need is sick. The failure is neither “on your machine” nor necessarily “inside the app.” It is somewhere in the middle, where most users have the least visibility.
Cloudflare’s reported updates gave customers something concrete: increased error rates, latency, and a fiber cut in Eastern North America. That is better than a vague “some users may be affected” holding statement. But the recurring complaint across internet outages is that status pages often lag the lived experience of customers who are already handling support tickets, executive pings, and incident bridges.
There is a structural reason for that lag. Vendors do not want to declare a broad incident before they understand its contours, especially when symptoms may be caused by upstream carriers, customer routing, or unrelated service failures. But customers do not need perfect root cause in the first ten minutes. They need confirmation that they are not alone and a rough description of the failure domain.
This is where the industry still underperforms. The best incident communications separate certainty from uncertainty: here is what we know, here is what we suspect, here is what is not yet confirmed, and here is when we will update again. That format is more useful than premature precision or sterile boilerplate.
That triage spiral is exhausting because the symptoms are noisy. Some users can reach a service while others cannot. Mobile networks may behave differently from office broadband. VPN users may see one path while unmanaged home users see another. A browser refresh may work once, then fail again.
Windows environments add their own complications. Microsoft Teams, Entra ID authentication flows, web-based admin portals, remote monitoring tools, SaaS finance platforms, and browser-delivered line-of-business apps all become part of the same user-facing mess. An employee does not care whether the root cause is CDN latency, DNS resolution, TLS negotiation, or a congested route. They care that the thing they use to work is broken.
The correct sysadmin posture is therefore skeptical but calm. Do not assume every simultaneous complaint has one cause, but do not waste the first half hour reinstalling clients and clearing browser caches when public telemetry shows a broad internet event. The fastest path to sanity is correlation: internal monitoring, external probes, vendor status pages, traceroutes, DNS checks, and user reports from different networks.
That shift changes what “Windows is down” means. A perfectly healthy Windows 11 machine can feel useless if the user cannot authenticate to a cloud app, open a Teams meeting, reach a SharePoint document, load a web dashboard, or access a remote management console. The operating system is running; the work environment is not.
This is especially relevant for organizations that have moved aggressively into zero-trust access models. Replacing old VPN concentrators with identity-aware edge access can improve security and usability, but it also changes the dependency graph. The edge provider is now part of the path to internal tools, not just public websites.
There is no reason to panic about that model, but there is every reason to document it. If your business depends on a provider for DNS, CDN, WAF, access control, and application routing, that provider is no longer just a vendor. It is a tier-one operational dependency.
A service can be healthy in its origin environment while unreachable or degraded for a subset of users. A status page can be green while a transit path is congested. A cloud region can be functioning while an edge network or carrier route makes the user experience unacceptable. This is where synthetic monitoring from multiple geographies and networks earns its budget.
The mistake is to treat “multi-region” as a magic shield. Multi-region application design helps when an origin fails. It may do little if DNS, edge routing, identity, or a shared network provider becomes the bottleneck. Real resilience requires looking at the entire request path, not just the server-side architecture.
For smaller organizations, that sounds intimidating. It does not have to mean building a global network operations center. It can start with a simple dependency map, an incident checklist, and monitoring that answers one practical question: can users on different networks reach the services we consider critical?
That split is why infrastructure outages now become mainstream news. The affected brands are familiar, but the underlying providers are not. Most people do not think about Cloudflare unless they see an error page, encounter a CAPTCHA, or read about an outage. Yet Cloudflare’s role is precisely to be invisible when things work.
The invisibility creates a trust problem. Users do not choose the CDN, DNS provider, or transit path behind the services they use. They inherit those decisions from companies, and companies inherit many of them from their vendors. When something breaks, the accountability chain is hard to see.
This is also why “just use another provider” is not a serious answer during an active incident. Migrating DNS, CDN, WAF, or zero-trust access under pressure is risky, slow, and often impossible without prior architecture work. Resilience has to be designed before the backhoe arrives.
But short duration should not be confused with low importance. Brief outages during peak business hours can expose brittle support processes, weak vendor communications, and shallow dependency inventories. They also train users to distrust systems that are otherwise highly reliable.
The pattern is what matters. Over the past several years, major outages involving cloud regions, CDNs, DNS providers, identity platforms, and collaboration suites have repeatedly shown the same paradox: the internet is distributed enough to survive immense stress, but concentrated enough that a few providers can make disruption feel universal.
Cloudflare is not uniquely guilty of that concentration. It is one of several companies that help the modern internet function at scale. The criticism is not that Cloudflare exists, but that too many organizations treat edge infrastructure as a commodity toggle rather than a core part of their reliability posture.
The second step is deciding which dependencies deserve alternate paths. Not every service needs an expensive failover design. But some do. If your customer portal, payment flow, remote access system, or executive communications depend on a single edge provider, that is a business decision, not just an infrastructure detail.
The third step is to rehearse communications. Users forgive outages faster than silence. A simple internal banner saying “we are tracking a regional internet infrastructure issue affecting multiple external services” can prevent hundreds of duplicate tickets. It also buys the technical team room to investigate without pretending certainty it does not yet have.
Finally, teams should distinguish between mitigation and theater. Clearing caches, rebooting endpoints, and reinstalling apps may make users feel like something is happening, but during a broad network event those actions often waste time. The better move is to verify from multiple networks, monitor vendor updates, preserve evidence, and communicate clearly.
A Fiber Cut Became an Internet-Wide Anxiety Test
The first wave of complaints reportedly accelerated shortly after 9:30 a.m. Eastern time, with Downdetector showing spikes not only for Cloudflare but also for AWS and a long list of consumer and workplace services. That pattern is familiar now: users do not experience the internet as a stack of providers, transit routes, caches, authentication gateways, DNS resolvers, and application backends. They experience it as “Teams is broken,” “Reddit will not load,” or “my browser is timing out.”Cloudflare’s own explanation pointed to increased error rates and latency, then to a fiber cut in Eastern North America. That matters because it suggests a physical network event rather than a code deployment, platform bug, or cyberattack. But for the end user, the distinction was mostly academic during the outage window. If a login request fails, a social feed freezes, or a SaaS dashboard spins forever, the failure mode looks the same.
The incident also collided with the most sensitive part of the workday. Morning outages in the U.S. hit authentication, chat, meetings, dashboards, order systems, and monitoring workflows just as businesses are coming online. A few minutes of degraded traffic can trigger an outsized response because everyone is trying to answer the same question at once: is this our network, our vendor, our cloud region, or the public internet?
That uncertainty is why Cloudflare incidents feel larger than their formal blast radius. The company sits in front of websites, APIs, identity flows, zero-trust access products, DNS services, and security controls. When those paths slow or fail, the symptoms scatter across brands that may not seem related to one another.
Downdetector Measured Panic as Much as Outage
Downdetector’s numbers are useful, but they are not a clean measurement of root cause. The reported spikes for Cloudflare, AWS, X, Reddit, Zoom, Teams, Robinhood, Discord, Canva, Fortnite, and others show that users were seeing failures across a wide surface area. They do not prove that every affected service failed for the same reason.That distinction matters because outage dashboards are often treated like forensic tools when they are really public smoke alarms. A spike tells us that a meaningful number of people experienced trouble at roughly the same time. It does not, by itself, tell us whether the culprit was Cloudflare, AWS, a transit provider, a regional carrier issue, a service-specific bug, or a chain reaction among several of them.
Still, smoke alarms are not useless just because they are imprecise. In incidents like Monday’s, Downdetector often becomes the fastest shared vocabulary for users and help desks. If your company’s monitoring is green but employees cannot reach third-party services, a public surge of complaints can help separate local misconfiguration from a broader event.
The danger is that public dashboards can amplify confusion. A major platform may show a spike because its own service is down, because its users traverse a degraded path, or because people see other outage reports and test the service at unusual volume. Outage reporting is both telemetry and crowd behavior.
AWS Was in the Conversation, but Cloudflare Was the Cleaner Signal
The user reports also mentioned AWS, which is unsurprising. AWS is embedded in so many application stacks that almost any web disruption invites speculation about us-east-1 or another major region. But the stronger public signal on Monday was Cloudflare’s own acknowledgment of network problems and its reference to a fiber cut in Eastern North America.That does not mean AWS complaints were imaginary. Users may have been unable to reach AWS-hosted applications through degraded routes, or some services may have had their own parallel trouble. It does mean that lumping AWS and Cloudflare together as a single outage risks flattening the incident into a generic “the cloud is down” story.
For IT teams, that difference is operationally important. If AWS control planes are failing, the mitigation playbook looks one way. If a CDN, DNS, security edge, or transit route is impaired, the playbook looks different. The correct response may involve bypass rules, alternate endpoints, failover routing, status messaging, or simply waiting for upstream recovery.
The broader lesson is that public cloud and internet edge providers are now so intertwined that users perceive them as one dependency. The web’s architecture is distributed, but its failure experience is often centralized.
The Internet Edge Is Now a Critical Business System
Cloudflare began life in the public imagination as a CDN and DDoS protection company, but that description undersells what providers like it have become. The modern edge handles traffic acceleration, bot filtering, TLS termination, API shielding, DNS, zero-trust access, browser isolation, object storage, serverless compute, and traffic steering. In some environments, Cloudflare is not merely in front of the website; it is part of the security boundary.That makes edge-provider outages unusually disruptive. A database outage may break one application. An identity outage may block a class of users. An edge outage can make many unrelated services appear unreachable, slow, or unreliable because it sits at the front door.
This is the bargain many organizations have knowingly accepted. Cloudflare and similar providers offer global scale, attack absorption, performance gains, simpler certificate management, and a practical way for smaller teams to operate with infrastructure sophistication they could never build alone. The tradeoff is concentration risk.
There is no serious return to a romantic old internet where every business runs its own globally resilient network. The economics do not work, and the security burden would be worse for most organizations. The real question is whether businesses understand where their dependencies are concentrated and whether their continuity plans reflect that reality.
Physical Infrastructure Still Gets the Final Vote
The phrase “fiber cut” has a way of making the cloud sound less magical. For all the abstraction layered above it, internet availability still depends on ducts, rights of way, conduits, trenches, poles, carrier hotels, and backhaul paths. One damaged segment can force traffic onto alternate routes, create congestion, increase latency, and expose assumptions that looked safe in architecture diagrams.The cloud industry sells redundancy, and often delivers it. But redundancy is not the same as infinite independence. Providers may have multiple routes that share physical corridors, depend on common carriers, or converge at the same exchange points. A single cut should not take down the internet, but it can degrade enough high-value paths to make millions of users notice.
This is why “localized” incidents can feel global. If the affected region sits between dense user populations and major application hosting footprints, the problem is not geographically contained in the way a weather map might imply. Traffic that begins in North America and targets services in Europe, or vice versa, can cross exactly the kind of path where a regional fiber event becomes a transatlantic performance problem.
For WindowsForum readers, this is the piece worth lingering on. Your laptop, browser, Teams client, VPN agent, and endpoint security stack may all be healthy while the path between them and the service they need is sick. The failure is neither “on your machine” nor necessarily “inside the app.” It is somewhere in the middle, where most users have the least visibility.
The Status Page Is Part of the Incident Now
Modern outages are judged not only by recovery time but by communications latency. Users and administrators expect official status pages to reflect reality quickly, and they become frustrated when public reports appear to move faster than vendor acknowledgment. In a major infrastructure incident, a status page is not marketing collateral; it is operational infrastructure.Cloudflare’s reported updates gave customers something concrete: increased error rates, latency, and a fiber cut in Eastern North America. That is better than a vague “some users may be affected” holding statement. But the recurring complaint across internet outages is that status pages often lag the lived experience of customers who are already handling support tickets, executive pings, and incident bridges.
There is a structural reason for that lag. Vendors do not want to declare a broad incident before they understand its contours, especially when symptoms may be caused by upstream carriers, customer routing, or unrelated service failures. But customers do not need perfect root cause in the first ten minutes. They need confirmation that they are not alone and a rough description of the failure domain.
This is where the industry still underperforms. The best incident communications separate certainty from uncertainty: here is what we know, here is what we suspect, here is what is not yet confirmed, and here is when we will update again. That format is more useful than premature precision or sterile boilerplate.
For Sysadmins, the Real Outage Is the Triage Spiral
When an event like this hits, sysadmins do not get the luxury of waiting for the postmortem. They have to decide whether to open an internal incident, whether to fail over services, whether to tell users to retry, whether to blame the ISP, whether to call the cloud vendor, and whether to reassure leadership that the company has not been breached.That triage spiral is exhausting because the symptoms are noisy. Some users can reach a service while others cannot. Mobile networks may behave differently from office broadband. VPN users may see one path while unmanaged home users see another. A browser refresh may work once, then fail again.
Windows environments add their own complications. Microsoft Teams, Entra ID authentication flows, web-based admin portals, remote monitoring tools, SaaS finance platforms, and browser-delivered line-of-business apps all become part of the same user-facing mess. An employee does not care whether the root cause is CDN latency, DNS resolution, TLS negotiation, or a congested route. They care that the thing they use to work is broken.
The correct sysadmin posture is therefore skeptical but calm. Do not assume every simultaneous complaint has one cause, but do not waste the first half hour reinstalling clients and clearing browser caches when public telemetry shows a broad internet event. The fastest path to sanity is correlation: internal monitoring, external probes, vendor status pages, traceroutes, DNS checks, and user reports from different networks.
The Windows Desktop Has Become a Thin Client to Someone Else’s Edge
The traditional Windows support model assumed that many problems lived on the endpoint: drivers, patches, local network settings, malware, broken applications, corrupt profiles. Those problems still exist. But the daily Windows experience has shifted heavily toward web-backed services, cloud identity, endpoint management, and SaaS applications that are only as reliable as the network path to them.That shift changes what “Windows is down” means. A perfectly healthy Windows 11 machine can feel useless if the user cannot authenticate to a cloud app, open a Teams meeting, reach a SharePoint document, load a web dashboard, or access a remote management console. The operating system is running; the work environment is not.
This is especially relevant for organizations that have moved aggressively into zero-trust access models. Replacing old VPN concentrators with identity-aware edge access can improve security and usability, but it also changes the dependency graph. The edge provider is now part of the path to internal tools, not just public websites.
There is no reason to panic about that model, but there is every reason to document it. If your business depends on a provider for DNS, CDN, WAF, access control, and application routing, that provider is no longer just a vendor. It is a tier-one operational dependency.
The Cloud’s Biggest Risk Is Not Always the Cloud Region
Enterprise resilience planning often fixates on cloud regions, and for good reason. A major AWS, Azure, or Google Cloud region failure can cause enormous disruption. But Monday’s reports are a reminder that the path to the cloud can be just as important as the cloud itself.A service can be healthy in its origin environment while unreachable or degraded for a subset of users. A status page can be green while a transit path is congested. A cloud region can be functioning while an edge network or carrier route makes the user experience unacceptable. This is where synthetic monitoring from multiple geographies and networks earns its budget.
The mistake is to treat “multi-region” as a magic shield. Multi-region application design helps when an origin fails. It may do little if DNS, edge routing, identity, or a shared network provider becomes the bottleneck. Real resilience requires looking at the entire request path, not just the server-side architecture.
For smaller organizations, that sounds intimidating. It does not have to mean building a global network operations center. It can start with a simple dependency map, an incident checklist, and monitoring that answers one practical question: can users on different networks reach the services we consider critical?
Consumers Felt Chaos; Businesses Felt Dependency
For consumers, the outage was an annoyance: timelines stalled, game services failed, apps timed out, and social platforms filled with jokes about half the internet being broken. For businesses, the same event carried a different weight. Every failed login, missed meeting, delayed trade, frozen design tool, or inaccessible support portal becomes lost time and reputational risk.That split is why infrastructure outages now become mainstream news. The affected brands are familiar, but the underlying providers are not. Most people do not think about Cloudflare unless they see an error page, encounter a CAPTCHA, or read about an outage. Yet Cloudflare’s role is precisely to be invisible when things work.
The invisibility creates a trust problem. Users do not choose the CDN, DNS provider, or transit path behind the services they use. They inherit those decisions from companies, and companies inherit many of them from their vendors. When something breaks, the accountability chain is hard to see.
This is also why “just use another provider” is not a serious answer during an active incident. Migrating DNS, CDN, WAF, or zero-trust access under pressure is risky, slow, and often impossible without prior architecture work. Resilience has to be designed before the backhoe arrives.
The Outage Was Short, but the Pattern Is Durable
Reports indicated that many services began recovering within the hour, with complaint volumes dropping as mitigation and rerouting took effect. That is good news. A short-lived degradation is far better than a cascading all-day failure, and it suggests the network did what resilient networks are supposed to do: absorb damage, reroute traffic, and stabilize.But short duration should not be confused with low importance. Brief outages during peak business hours can expose brittle support processes, weak vendor communications, and shallow dependency inventories. They also train users to distrust systems that are otherwise highly reliable.
The pattern is what matters. Over the past several years, major outages involving cloud regions, CDNs, DNS providers, identity platforms, and collaboration suites have repeatedly shown the same paradox: the internet is distributed enough to survive immense stress, but concentrated enough that a few providers can make disruption feel universal.
Cloudflare is not uniquely guilty of that concentration. It is one of several companies that help the modern internet function at scale. The criticism is not that Cloudflare exists, but that too many organizations treat edge infrastructure as a commodity toggle rather than a core part of their reliability posture.
The Practical Lesson Is to Map the Invisible Middle
For IT teams, Monday’s incident should prompt a boring but valuable exercise: write down the external services that sit between users and work. That includes DNS, CDN, WAF, SSO, MFA, endpoint management, remote access, monitoring, email security, SaaS platforms, and the carriers or ISPs that matter most to your offices. Boring inventories become very interesting when the internet starts throwing 5xx errors.The second step is deciding which dependencies deserve alternate paths. Not every service needs an expensive failover design. But some do. If your customer portal, payment flow, remote access system, or executive communications depend on a single edge provider, that is a business decision, not just an infrastructure detail.
The third step is to rehearse communications. Users forgive outages faster than silence. A simple internal banner saying “we are tracking a regional internet infrastructure issue affecting multiple external services” can prevent hundreds of duplicate tickets. It also buys the technical team room to investigate without pretending certainty it does not yet have.
Finally, teams should distinguish between mitigation and theater. Clearing caches, rebooting endpoints, and reinstalling apps may make users feel like something is happening, but during a broad network event those actions often waste time. The better move is to verify from multiple networks, monitor vendor updates, preserve evidence, and communicate clearly.
Monday’s Cloudflare Disruption Leaves a Short Checklist Behind
The most useful reading of this outage is not that the internet is fragile in some simplistic sense. It is that reliability now depends on layers most users never see and many organizations only partially document. When one of those layers bends, the user-facing effect can look much larger than the underlying fault.- Cloudflare acknowledged network degradation on June 22, 2026, tied to a fiber cut in Eastern North America.
- Downdetector spikes showed widespread user pain, but those reports should be treated as symptoms rather than definitive root-cause evidence.
- AWS appeared in user reports, but the clearest public explanation centered on Cloudflare’s network path and related latency or error increases.
- Windows users and administrators may see healthy endpoints fail to complete cloud-dependent workflows when edge, transit, DNS, or identity paths degrade.
- Organizations should map critical dependencies before incidents, because emergency migration away from an edge provider is rarely realistic.
- Internal incident communications should state what is known, what is suspected, and when the next update will arrive, rather than waiting for perfect certainty.
References
- Primary source: The Sunday Guardian
Published: 2026-06-22T15:45:07.951126
Cloudflare Outage: Is Cloudflare Down Today? Thousands Users Report Widespread Internet Disruptions Across Major Platforms | Cloudflare Downdetector Status
AWS and Cloudflare outage reports surged Monday as users experienced website failures, app disruptions, and network delay while a fiber cut in Eastern North America was identified as a key factor, affecting major services including X, Reddit, Zoom, Discord and Microsoft Teams.
sundayguardianlive.com
- Related coverage: techradar.com
DoorDash was down for many — here's what happened in the major outage | TechRadar
DoorDash crashed today, but is now back onlinewww.techradar.com - Related coverage: pulsetic.com
Is Cloudflare Down? Increased HTTP 5xx Errors to us-east-1 from Western North America and Asia Pacific co-locations. | Pulsetic
Incident details: Increased HTTP 5xx Errors to us-east-1 from Western North America and Asia Pacific co-locations.. Cloudflare - started May 21, 2026 · 5:00 PM. Full timeline, user reports, and detection lead.pulsetic.com - Related coverage: radar.cloudflare.com
Outage Center | Cloudflare Radar
Explore the latest Internet traffic anomalies and verified outages.radar.cloudflare.com - Related coverage: cloudflare.statuspage.io
Cloudflare Status
Welcome to Cloudflare's home for real-time and historical data on system performance.cloudflare.statuspage.io
- Related coverage: tomshardware.com
Cloudflare's CTO apologizes after error takes huge chunk of the internet offline — 'we failed our customers and the broader internet' | Tom's Hardware
CTO blames bot mitigation bug triggered by routine config change.www.tomshardware.com
- Related coverage: downdetector.it
Cloudflare down? Current problems and outages - IT
Current problems for CloudFlare. Is your site having issues? Check it heredowndetector.it - Related coverage: isdown.app
Is Cloudflare North America Down? Check current status and user reports | IsDown
Check if Cloudflare North America is down right now. Live Cloudflare North America status, real-time outage detection, and instant alerts when Cloudflare North America has issues. Free 14-day trial.
isdown.app
- Related coverage: outage.report
Cloudflare down? Outage map, service status, incidents history
See if Cloudflare is down or it's just you. Check current status and outage map. Post yours and see other's reports and complaints
outage.report
- Related coverage: checkupstream.com
Cloudflare Reliability & Status — CheckUpstream
Track Cloudflare uptime, incidents, and community-reported error rates over the past 30 days. Real-time reliability data from CheckUpstream.www.checkupstream.com - Related coverage: cf-assets.www.cloudflare.com
- Related coverage: cert-mu.govmu.org
Microsoft Word - Security Alert - Google Cloud and Cloudflare hit by widespread service outages.docx
PDF documentcert-mu.govmu.org
