Summary

  • Cloudflare created incident 7dk3g4k188ky at 11:05:13 UTC on 3 August and classified its impact as minor.
  • The first notice said customers with dedicated IPv4 egress IPs homed in London might be unable to reach the public Internet.
  • The affected component was Gateway, which moved from operational to degraded performance.
  • Cloudflare identified the issue at 11:25:29, implemented a fix by 13:10:13 and then monitored the result.
  • The incident was resolved at 13:23:03, after 2 hours 17 minutes 50 seconds; the monitoring interval lasted just under 13 minutes.
  • Cloudflare did not publish a cause, affected-customer count, traffic denominator, workaround or evidence of a security or data-loss event.

A stable address is both a control and a dependency

Dedicated egress exists because the public Internet usually needs a recognisable counterpart. A company can present a fixed outbound IPv4 address to a supplier, banking service or administrative endpoint, and the destination can allow that identity without opening access to an entire shared cloud range. The same address can support logging, contractual controls and investigation because activity has a more durable network origin.

The incident shows the architectural price of that convenience. The first Cloudflare update did not describe a broad loss of Gateway or a London-wide network failure. It identified a smaller cohort: customers whose dedicated egress addresses were homed in London. For those users, the stable address and the provider path delivering it formed one dependency. If that path could not carry traffic to the public Internet, an external destination might remain fully operational while the customer still could not reach it.

That distinction changes both diagnosis and resilience planning. An application team seeing failed connections might first suspect the destination, DNS or local access policy. The status notice directs attention instead to the outbound identity layer. It also warns against treating the address as a passive label. A dedicated IP is a service delivered through routing, Gateway state and regional infrastructure.

The failure domain was narrow, not trivial

Cloudflare labelled the impact minor and used conditional language: affected customers “may be unable” to reach the public Internet. The description rules out several sweeping claims. It does not support saying all Cloudflare customers were offline, all Gateway sessions failed, every dedicated egress customer was affected, or London’s wider connectivity was lost.

Narrow scope does not make the dependency unimportant to an individual organisation. A business may deliberately route privileged administrative traffic, payment reconciliation or partner API calls through a dedicated address. If the remote party accepts only that source, simply finding another working Internet connection does not restore the authorised path. The customer’s business impact therefore depends on what relied on the address, not on the provider’s platform-wide incident label alone.

The missing denominator prevents a measured severity judgment. Cloudflare did not publish the number of affected accounts, the proportion of London-homed dedicated addresses, failed request volume, packet loss, destination mix or duration experienced by each customer. “Minor” is a provider classification. It is not a quantified customer-loss estimate.

The public timeline separates diagnosis from recovery

The lifecycle began at 11:05:13 UTC. Cloudflare’s initial statement described the observed reachability problem and said it was investigating. At 11:25:29, about twenty minutes later, the status changed to identified and the company said a fix was being implemented. That is evidence that the operator had moved from symptom recognition to a chosen corrective action; it is not evidence that the action had already succeeded.

At 13:10:13, Cloudflare said the fix had been implemented and moved the incident into monitoring. The final resolution followed at 13:23:03. The public record therefore contains a useful sequence: detection, diagnosis, implementation, observation and closure. The 12-minute-and-50-second monitoring interval is short enough that customers should not read it as a long stability test, but it is still a distinct stage rather than an immediate declaration of success.

Resolution means Cloudflare returned Gateway from degraded performance to operational and closed its incident. It does not disclose independent customer probes, per-destination success rates or the moment every affected session recovered. Provider state is important operational evidence; it is not a substitute for customer-side verification.

Recovery did not reveal the cause

Nothing in the captured record attributes the incident to software, configuration, capacity, a carrier, a specific facility or a routing change. Nor does it name the corrective action. A successful fix can narrow an operator’s internal diagnosis, but the public audience cannot infer which mechanism was changed.

That absence is especially important for dedicated egress. Similar outward symptoms could arise from address advertisement, translation state, Gateway policy, route selection or another dependency. Listing possibilities can help an engineer plan tests, but it must not become retrospective attribution. The only supported technical boundary is that the named Gateway component degraded for the London-homed dedicated IPv4 egress cohort.

The record also offers no basis for a cyberattack, compromise, data exposure or data loss claim. An inability to reach the public Internet is an availability symptom. Security conclusions require separate evidence. Treating any cloud-network interruption as an attack would confuse consequence with cause.

Customer continuity depends on preserving identity as well as reachability

A conventional failover may send traffic through another region or provider. For dedicated egress, that alternative works only if the destination recognises the replacement source and the organisation’s security policy permits it. A technically live backup that presents an unapproved address can still fail at the partner’s firewall.

Operators therefore need two continuity maps: where traffic can exit, and which identities external systems will accept. A tested secondary egress address, pre-authorised with critical partners, can reduce dependence on a single home. But duplication also expands the allowlist and governance surface. The answer is not unlimited addresses; it is a deliberately bounded set, owners for each partner rule, expiry controls and exercises that prove the backup path works.

During an incident, teams should preserve timestamps, destination results, source addresses and transaction identifiers. Read operations can often be retried safely. Writes may need reconciliation before repetition because the remote service could have acted even if the response path failed. Cloudflare did not report duplicated transactions or data damage; this is continuity discipline for an ambiguous reachability failure, not a claim about this incident’s consequences.

The next disclosure should explain the dependency that failed

A useful post-incident note would identify the technical fault domain, the corrective action, the size of the exposed cohort and whether every London-homed dedicated IPv4 egress address shared the same dependency. It would also say whether failover existed, whether customers needed to change anything, and how recovery was validated beyond the component status.

Those facts would let customers decide whether the episode was a one-off defect or evidence that their outbound identity lacks diversity. Until then, the correct conclusion stays bounded. Cloudflare resolved a minor Gateway incident affecting the ability of a defined London-homed dedicated IPv4 egress cohort to reach the public Internet. The event demonstrates how a stable network identity can become an operational choke point; it does not establish a citywide outage, a universal Gateway failure or a security event.

Sources