Gone offline: how Cloudflare Radar detects Internet outages

Detecting outages with traffic anomaly events

Cloudflare Radar's Outage Center documents observed Internet disruptions, but it has always been a curated list: each entry requires contextual validation from ISP updates, government announcements, news reports, or external sources like Georgia Tech's IODA project. That manual workflow means not every disruption we detect ends up in the center, and those that do appear only after the context is found.

Starting today, we're making the anomaly detection process itself public. Radar will surface anomalous traffic events for countries and autonomous systems (ASes) as they're detected — the same events that previously triggered our internal validation workflow. A related announcement covers how to subscribe to notifications for new anomaly events or Outage Center entries at a location or network level. Traffic anomalies currently refer only to drops in traffic, not unexpected spikes.

How anomalies are classified

The new "Traffic anomalies" table on the Outage Center page shows the real-time status of each detection:

• An automatically detected anomaly is initially marked Unverified.
• Validation of unverified entries yields one of two outcomes:
  • Verified, when the anomaly is confirmed across multiple internal data sources (and possibly external ones), at which point it may also generate an Outage Center entry if we find supporting context.
  • False Positive, when the anomaly cannot be corroborated across data sources, removing it from the traffic anomalies table. If you received a notification for an anomaly that no longer appears on Radar, this is why.
• Entries can also be manually added with a Verified status when we observe and validate a traffic drop that is noticeable but too small for the detection algorithm to catch.

What traffic volume signals look like in practice

Our analysis relies on several internal data sources — DNS, HTTP, NetFlow, and Network Error Logs (NEL) — with entities identified by IP geolocation for locations and IP allocation for ASes. We treat each signal as a univariate time-series; using more than one signal adds redundancy and confidence rather than feeding a multivariate model. The range of real-world patterns we encounter is broad, even among just six examples selected from the roughly 700 entities for which anomaly detection currently runs.

In the ideal case, traffic looks like Australia (AU): a stable weekly pattern with a gently positive trend, meaning average traffic from Australian users is rising over time.

This structure becomes clear with time-series decomposition. Applying Seasonal-Trend decomposition using LOESS (STL) with a weekly period to Australia's traffic separates the signal into its parts:

The seasonal component captures the weekly pattern expected from human-driven Internet traffic, the trend moves slowly relative to the signal level, and the residual ideally resembles white noise — all structure is explained by the seasonal and trend components.

Real-world cases diverge. AS15964 (CAMNET-AS) shows a daily rather than weekly pattern, plus a permanent offset in traffic after the first four days (marked with a blue dashed line in the source data). The red background indicates an outage for which no reporting was ever found — visible only in our data and other Internet observatories. Building an algorithm that flags patterns like this, with no external context, is precisely the goal.

French Guiana (GF) demonstrates further variability: data offsets on August 9 and 23, an amplitude change between August 15 and 23, and a separate outage with confirmed context visible in Radar's historical view.

Scheduled outages, such as those for AS203214 (HulumTele), are the easiest to detect — traffic drops to values unique to outages, unlikely to be confused with normal fluctuation. But they pose a different hazard: if these government-directed events recur with the same frequency, a naive weekly-pattern model would eventually treat them as expected traffic.

An outage in Kenya resembles the HulumTele pattern but with a less dramatic drop, together with upward spikes that follow no clear pattern — possible outliers we would want to clean from the data before modeling.

Madagascar (MG) serves as our primary example throughout this discussion. The signal shows pronounced weekends (blue background), a holiday — the Assumption of Mary — in green, and an outage in red. Strikingly, weekends, the holiday, and the outage produce roughly the same traffic volume. The outage reveals itself only because traffic initially rises as on a normal working day before abruptly falling. That tell is what a good detection algorithm needs to exploit.

Why statistical simplicity wins

The six examples above are representative of the variability we face across ~700 monitored entities. Effective time-series modeling would normally require extensive preprocessing: outlier removal, detecting and adjusting for short- and long-term data offsets, and handling shifts in variance, mean, or magnitude. Then there is the temporal dimension: knowing when to expect holidays, applying daylight saving time shifts, and dealing with local time zones for each entity — including locations spanning multiple zones or ASes whose traffic crosses zones. Some of these adjustments cannot even run in near-real-time; a change in seasonality, for instance, only becomes evident after observing the new pattern for a while.

Given all this, we deliberately chose an algorithm combining basic preprocessing and statistics. The approach matches our expectations for the data's characteristics, is easy to interpret, gives us control over the false positive rate, runs quickly, and sidesteps many of the preprocessing burdens outlined above.

The launch scope — around 700 countries and autonomous systems — is not the full universe of entities on the Internet. A useful model requires a sufficiently strong traffic signal, and for smaller or sparsely populated countries, or ASes from which we see little to no traffic, that signal is simply too weak. We're starting with entities that have strong signals and/or a history of traffic anomalies, weighted toward major networks that represent meaningful shares of a location's population or have shown past disruptions.

How an anomaly is flagged

Cloudflare Radar's outage detection begins with a simple premise: compare observed traffic against an expected baseline. If reality falls significantly short of that expectation, it's flagged as an anomaly — in this context, always a drop in traffic. The system generates a multi-point forecast from historical patterns and checks each new 15-minute traffic bucket against it, looking for deviations that meet specific criteria.

Three business requirements shaped the design:

• Focus on traffic that reflects human activity, not automated or background traffic.
• Detect anomalies as soon as possible after data is ingested and processed — ideally using the most recent data point.
• Prioritize a low false positive rate over a high true positive rate, since Cloudflare Radar is a publicly visible notification service.

Choosing what to watch

Not all entities produce signals worth tracking. For autonomous systems (ASes), Cloudflare uses user estimates from APNIC to filter for relevance. An AS is only tracked if it accounts for at least 1% of the estimated Internet users in its location; the table below shows how this looks for Portugal, where AS15525 (MEO-EMPRESAS) falls short of the cutoff.

Locations are not excluded upfront — the goal is maximum coverage — but they are subject to the same downstream quality filter. After testing several metrics, the strongest predictor of a stable signal turned out to be data volume, so entities that don't meet a threshold of unique daily IPs over a two-week period are removed. That threshold was determined by visual inspection.

Building the forecast

Traffic is aggregated in 15-minute buckets, and the system forecasts four buckets (one hour) ahead. The forecast method is deliberately straightforward:

1. The 24 hours immediately before the forecast window serve as the reference pattern.
2. Using Euclidean distance, the system finds the six most similar 24-hour periods in the past 28 days (plus the reference day itself, totaling 29 days of history).
3. The forecast is the median of those six matches, with one adjustment: for an even number of values, the lower quartile is used instead, making the forecast more conservative.

The 28-day window ensures weekly seasonality appears at least four times, bounds processing time, and limits risk from longer-term trend drift. Six similar days was chosen empirically: on a normal weekday, roughly four of the matches will be the same weekday, with two others that may be unrelated. Since the median drives the forecast, those two outliers are effectively discarded. The figure below shows how the system handles a holiday transition that looks like a Friday-to-Saturday pattern.

Holidays present a useful test case. A midweek holiday may resemble a weekend transition; with only 28 days of history, the system might find just three true matching transitions and fall back to three regular working days as closest alternatives. Using the lower quartile for even-numbered sets pushes the forecast downward in such cases, reducing the chance of a false positive at the cost of missing some weaker anomalies.

In an outage, the reference itself contains low traffic because it's a transition from Sunday to Monday. The system's nearest matches are then likely Saturdays or Sundays, also low-traffic periods. The forecast therefore expects a normal Monday's upward trend, while the observed outage traffic stays well below that expectation, as shown below.

This pattern-based approach handles regular seasonality, holidays, and moving events without explicitly encoding that information. It does have failure modes — particularly when data is shifted or offset — which is why Cloudflare uses multiple data sources as a safeguard against artifacts.

Comparing forecast to reality

Once the forecast and actual values are ready, the system computes a relative change metric. Because only drops are of interest, the actual will always be lower than the forecast.

Two additional rules are applied before an anomaly is declared:

• Minimum magnitude: The gap between actual and forecast must be at least 10% of the signal's dynamic range, computed as the difference between the 95th and 5th percentiles of the selected data. This prevents false alarms during off-peak hours, when a large relative change could represent only a tiny absolute shift in traffic — for example, a 20% drop from 100 Gbps is significant, while a 50% drop from 20 Mbps is not.
• Two anomaly types:
  • Sustained anomaly: The relative change stays below a threshold α for all four data points in the forecast window, catching weaker but prolonged drops.
  • Point anomaly: The relative change of the final data point falls below a stricter threshold β (with β < α, both negative; roughly -0.6 and -0.4 respectively). This captures sudden, short-lived drops while filtering out stochastic noise.

Both α and β were tuned empirically to maximize detection while keeping the false positive rate manageable.

When does an outage end?

Flagging the start of an anomaly is only half the job. Knowing when traffic returns to normal matters for two reasons:

• While an anomaly is active, its data must not be used as a reference for future forecasts — that would contaminate the baseline.
• Recording the duration lets the system flag and replace anomalous data points, preventing them from being used as matches later. This is especially important for ASes with recurring outages at the same time of day, like the AS203214 (HulumTele) example, where repeated anomalies could otherwise become the new normal.

Once an anomaly is declared, the reference remains frozen until traffic recovers. Recovery requires a stay of at least four hours with no anomalies, using thresholds looser than α. This grace period collapses bouncing traffic patterns into a single event, avoiding a flurry of duplicate notifications when a drop recovers and drops again.

Limits of the approach

Internet traffic is generally predictable, which makes a relatively simple anomaly detector viable. The real challenge is context: time-series data varies widely by entity, contains artifacts, and must be assessed in near real-time. The pattern-matching forecast with lowered median handles most seasonal, holiday, and recurring patterns well, and the static thresholds keep false positives low at the expense of missing anomalies that aren't steep enough. That is an acceptable tradeoff for a public-facing system, and Cloudflare plans to keep expanding the entities it monitors and refining the algorithm to broaden the range of detectable events.