Confidence
1- Information type
- CLOUDFLARE appears with one supporting public reference but no confirmed operator yet; BTW tracks it to link these public clues to a responsible organisation and its relationships.
Related details
CLOUDFLARE appears in public RDAP/WHOIS registry context as a entity record with handle MNT-CLOUDFLARE.
public network registry
Last updated: 2026-05-24
Current status
Services
1Related research
13- Cloudflare Keeps a Post-Quantum API That No Longer Changes the Setting
Automatic Key Exchange separates algorithm selection from algorithm restrictions. A surviving legacy endpoint no longer controls either in the way its old name suggests.
Primary articlePublished 2026-09-08 - Cloudflare records 48-minute 5xx window on Singapore–North America path
Cloudflare says some customers encountered elevated 5xx errors and timeouts between North American origins and its Singapore data centre from 01:06 to 01:54 UTC on 23 August. The incident was resolved, but its public narrative appeared after the stated impact window had closed.
Primary articlePublished 2026-08-23 - Cloudflare applied an Asia-Pacific network fix in eight minutes, but recovery stayed unmeasured
Cloudflare moved a broadly labelled Asia-Pacific network-performance incident from investigation to monitoring in 8 minutes 36 seconds. The record remained open more than 86 minutes later and named no location, product, symptom or customer denominator, so the fix timestamp cannot double as a customer-recovery timestamp.
Primary articlePublished 2026-08-21 - Cloudflare’s Workers regressions exposed two kinds of release contract
Cloudflare closed two separate Workers incidents on 4 August: a runtime exposed an unintended `Temporal` global whose clock reported 1970, while a deployment assertion rejected Workers using `nodejs_compat` with a new compatibility date. Neither was described as a platform-wide outage, and Cloudflare did not give them a common cause. Together, however, they show why a release contract must cover both what an application detects at runtime and what the control plane permits at deployment.
Primary articlePublished 2026-08-04 - Cloudflare’s Workers Builds incident shows why software can be live but unable to change
Cloudflare marked an August 3 Workers Builds incident resolved after one hour and 51 minutes. The revealing moment came earlier: at 15:38 UTC, builds were no longer failing, yet users could still encounter delays. That interval separates two kinds of availability—keeping an existing deployment in place and retaining the ability to compile and release the next one. Cloudflare did not disclose a root cause, customer count or runtime impact, so the event supports a precise lesson about change capacity, not a claim of a global Workers outage.
Primary articlePublished 2026-08-03 - Cloudflare’s London egress incident exposed the narrow risk inside a stable outbound identity
Cloudflare restored Gateway service after a two-hour incident in which customers using dedicated IPv4 egress addresses homed in London could have been unable to reach the public Internet. The public record is precise about the affected path and the five operational states, but sparse about scale and cause. That combination matters. A dedicated egress address gives an organisation a durable identity for allowlists and policy, yet it also concentrates outbound traffic on a provider-managed dependency whose failure can interrupt destinations that are otherwise healthy.
Primary articlePublished 2026-08-03 - Cloudflare's 2024 1.1.1.1 Incident Made Route Propagation an Accountability Test
Cloudflare's June 2024 1.1.1.1 incident showed that address records, route-origin authorization, transit policy, blackhole controls and public route observations protect different parts of reachability. Accountability begins with the routes that running networks accepted and propagated.
Primary articlePublished 2026-08-03 - Cloudflare's January 2026 IPv6 Route Leak Made Empty Export Policy an Accountability Test
Cloudflare's account of a 25-minute IPv6 route leak shows why routing automation must be judged by rendered export semantics, Adj-RIB-Out changes and the paths the Internet actually observed.
Primary articlePublished 2026-08-02 - Cloudflare's AI Labyrinth Turned Decoy Pages into a Crawler Control
Cloudflare introduced AI Labyrinth on 19 March 2025 as an opt-in defense for crawlers that ignored no-crawl directives. Instead of only rejecting a request, the service could expose suspected bots to linked, AI-generated decoy pages. The design joined deterrence and detection: waste an unwanted crawler's resources, then treat its decision to follow bot-only links as another signal. But Cloudflare's launch evidence described a mechanism, not an independently measured success rate.
Primary articlePublished 2026-08-13 - Cloudflare's July 2025 Crawler Controls Turned AI Access into an Edge Policy
On 1 July 2025, Cloudflare announced a permission-based approach to AI crawling for websites using its network. The change was not a universal paywall and did not prove that every crawler would comply. It was a set of distinct controls: an upfront choice for newly onboarded domains, managed `robots.txt` signals, edge-enforced blocking options, and a private-beta Pay Per Crawl experiment. Reading those layers separately shows what changed at the web edge—and what remained unproven.
Primary articlePublished 2026-08-13 - Cloudflare's 2026 BYOIP Outage Made Prefix-State Control an Accountability Test
A control-plane change withdrew customer-owned prefixes and exposed why address authority, service bindings, route intent, deployed configuration and public reachability need separate, continuously reconciled evidence.
Primary articlePublished 2026-08-02 - Spamhaus's 2013 DDoS Made Open DNS Recursion a Network Accountability Test
The March 2013 campaign showed how exposed recursive DNS, source-address spoofing and shared interconnection paths could turn individually small configuration failures into a large external cost. Accountability depends on proving which operator controlled each executable step and whether the repair worked.
Primary articlePublished 2026-08-02 - Cloudflare’s 70-minute incident separated its control plane from its edge
Cloudflare recorded a minor incident at 11:51:07 UTC on 31 July, initially warning that Dashboard and related-API requests might fail while Analytics was degraded. The event later expanded to Pages and Worker builds, entered monitoring at 12:43:57 and was marked resolved at 13:01:59. Cloudflare explicitly said cached-file delivery through its CDN and other Edge security features were unaffected. That separation matters: customers lost reliable access to management and build functions without evidence that ordinary cached traffic stopped flowing.
Primary articlePublished 2026-07-31
