Cloudflare Radar Adds Internet Outage Search: A New Check for Proxy Route Incidents

Cloudflare announced on September 8, 2026 that Radar search now includes Internet events and outages. Operators can search event descriptions or related entities such as locations, autonomous systems, bots, and top-level domains, then open the relevant Radar view. Event links preserve the event date range, and the results are also available to browser-based AI agents through WebMCP.

For teams running residential proxy, rotating proxy, market-research, ad-verification, or authorized data-collection workloads, this adds a useful external evidence source. A sudden regional failure may be a proxy-provider issue, a destination issue, a client regression, or a wider network event. Searchable outage context can shorten that first classification step—but it does not replace direct testing.

What changed

Previously, a team investigating a drop in success rate often had to navigate separate Radar views or already know which network, geography, or incident to inspect. The new search surface lets an operator start from the observed symptom: a location, AS number, bot name, top-level domain, or event description.

Preserved date ranges matter because proxy evidence should be compared inside the exact incident window. A matching country or network event from the wrong hour is not useful attribution.

Why proxy teams should care

Proxy failures are multi-layered. A client may successfully authenticate to a gateway while an upstream route, access network, or destination remains degraded. Conversely, a provider may have a localized inventory problem during an otherwise healthy Internet period.

External event evidence is most useful for separating four hypotheses:

• client or automation regression;
• proxy gateway or provider control-plane incident;
• exit-network or regional connectivity incident;
• destination-side outage, policy change, or throttling.

The search result narrows the investigation. Only your controlled measurements can show which layer affected your workload.

A six-step incident workflow

1. Freeze the incident window

Record the first and last observed failure in UTC. Preserve the proxy product, gateway, requested region, client version, address family, target class, and deployment version. Do not rewrite the window after looking at external events.

2. Separate transport from application outcomes

Keep DNS, TCP connect, proxy authentication, tunnel, TLS, HTTP status, content validation, and workflow completion as distinct stages. A regional decline in valid results with stable tunnel success tells a different story from widespread connection timeouts.

3. Build a control matrix

Compare the affected route with an approved direct control, a second proxy region, and—where contractually available—a second gateway. Keep destination, request profile, pacing, and time window aligned. Do not rotate multiple variables at once.

4. Search the external event context

Search the observed country, city, autonomous system, or outage description. Capture the institution, event label, and preserved date range in the internal incident record. Keep the external URL in internal tooling only; 98IP public pages remain free of outside links.

5. Test correlation boundaries

Ask whether the event overlaps the failure in time, geography, IP family, and network path. If the proxy issue began earlier, continued longer, or affected unrelated networks, the external event cannot explain the whole incident.

6. Define recovery by useful output

Do not close the incident when ping or DNS recovers. Require successful proxy authentication, expected exit geography, valid destination content, acceptable latency, and restored useful-result rate for a sustained window.

Minimum evidence packet

Create one row per bounded sample, not per uncontrolled retry:

• UTC timestamp and anonymous test identifier;
• requested and observed region;
• anonymous route, gateway, and exit fingerprints;
• address family and, where permitted, AS number;
• DNS, connect, tunnel, TLS, response, and validation result;
• latency and retry attempt number;
• control-route result;
• external event label and event-window overlap;
• final classification and confidence.

Never store proxy passwords, authorization headers, cookies, tokens, customer payloads, or unnecessary full IP addresses in the incident packet.

Guardrails against false attribution

An external event is corroborating context, not proof that a proxy provider caused or resolved an incident. Coverage can be incomplete, time boundaries can differ, and multiple failures can occur together. Preserve counter-evidence: healthy controls inside the affected region, failures outside it, or a client deployment that lines up more closely with the start time.

Also avoid using a public outage as permission to increase retries. Network disruption usually calls for lower concurrency, bounded retry budgets, jitter, and a circuit breaker. Aggressive rotation can hide the original path and amplify load.

Operational checklist

• [ ] Incident window fixed in UTC before research
• [ ] DNS, connect, authentication, tunnel, TLS, response, and content stages separated
• [ ] Direct and alternate-route controls collected
• [ ] IPv4 and IPv6 compared independently
• [ ] External event overlaps in time, geography, and network
• [ ] Retry volume bounded during degradation
• [ ] Provider escalation contains sanitized samples and aggregates
• [ ] Recovery requires valid useful output, not transport alone
• [ ] External sources stored internally without public outbound links

FAQ

Does a matching Radar event prove the proxy provider was not at fault?

No. It shows a wider event may have contributed. The provider could still have an independent failure, insufficient failover, or concentrated supply in the affected network.

Should every proxy error trigger an outage search?

Use it when failures cluster by time, geography, AS, or address family. Authentication errors and deterministic client configuration failures should be diagnosed at their own layer first.

Can this replace provider status pages?

No. Treat it as an independent context source alongside provider notices, client telemetry, destination checks, and controlled routes.

Related 98IP guides

• Test multi-region proxy routing policy
• Validate proxy geolocation by consensus
• Plan failover around route convergence

Compliance note

Use outage research and proxy tests only for authorized systems and lawful workloads. Respect destination terms, rate limits, privacy duties, and regional requirements. Keep probes bounded, redact sensitive routing evidence, and never use incident conditions to bypass access controls.

Source note: Cloudflare, Analytics Changelog, “Radar search now includes Internet events,” September 8, 2026.