0.7 ms to 1.1.1.1: How One Anchor Blinded Our Monitoring for Three Months

If you ping 1.1.1.1 and it answers, what have you learned? For three months we believed the answer was "this vantage point can reach the wider internet." It is not. On 23 August 2026 we measured the same address from several vantage points at the same time, and the numbers were not comparable in any useful sense.

This is a note about how we got that wrong, what it cost us, and how anyone can check the same thing in their own monitoring in about five minutes.

The same address, four very different distances

Each figure below is the mean round-trip time over 52 consecutive samples of 20 ICMP packets each, taken the same day from a different vantage point in our distributed measurement network. The anchor is identical in every row.

Three of those rows behave like normal internet paths. One does not. From Kyiv, 1.1.1.1 replies in well under a millisecond, while Google's resolver from the very same machine sits at 14 ms. The box is not unusually close to the internet in general. It is unusually close to that one address.

The traceroutes

Two paths from the same host, taken seconds apart. First, to 1.1.1.1:

Five hops, and the packet never leaves the metro. Now the same host to 8.8.8.8:

Eleven hops, and you can see exactly where the traffic leaves the city: between hop 6 and hop 8 the latency steps from 1.3 ms to 14.5 ms. That step is the thing we thought we were monitoring. On the 1.1.1.1 path, that step never happens.

Why the difference? Both addresses are anycast, so both are answered by whichever instance is topologically nearest. In Kyiv, an instance of one of them is effectively next door, reachable across local peering. Whether that is an edge node peering with the local network or something on the path answering for the address, our data cannot say, and for monitoring purposes it does not matter. What matters is that the path does not traverse the wider internet, so it cannot report on the wider internet.

The anchor even hides faults on its own path

Look again at hop 4 in the first traceroute: 33% packet loss, with individual samples ranging from 1.7 ms to 21.9 ms. That is a genuinely unhealthy hop. It has no effect on the measurement, because the anchor replies before the path gets that far. A monitoring system watching this anchor would report a perfectly healthy network while sitting one hop away from a link dropping a third of its packets.

What it cost us

We ran a correlation test to see whether a documented external stressor showed up in our reachability series. For the Kyiv vantage point we took every day on which public air-raid alerts were recorded for the city, and compared alert intensity against measured packet loss to the anchor.

Across 69 such days, mean reachability was 99.87%. Sixty-seven of the 69 days sat at 99.9% or better, including every one of the days with the heaviest alert activity. The result was a clean null.

We nearly published that null as a finding about network resilience. It was not a finding about the network. It was a finding about the anchor: we had been measuring a link inside the city that had no particular reason to fail, and correctly observing that it did not fail. The instrument had no sensitivity to the question being asked.

A null result from an instrument you have not validated is not evidence of absence. It is not evidence of anything.

What we changed

Three changes, all of them boring, none of them clever.

More than one anchor. Every vantage point now measures a global anchor, a second global anchor operated by a different organisation, and a peer inside the same region. Three destinations that fail for three different reasons are far harder to fool than one.

The first hop, explicitly. Each sweep now also measures the local gateway. If the first hop is clean and everything beyond it is not, the problem is upstream. If the first hop is dirty, it is the last mile. That single extra measurement separates two failure classes that a single anchor merges into one undifferentiated "degraded."

A usable sample size. We were sending six packets per cycle. Six packets cannot distinguish 5% loss from 0% loss; the smallest step it can express is 17 percentage points. We now send twenty. In the first cycle after the change, one vantage point recorded 19 of 20 packets to its primary anchor while both other anchors and the local gateway stayed clean, which located a 5% loss on one specific path. The old configuration would have rounded that to "fine."

We deliberately did not change which anchor feeds the alerting threshold. Redefining a metric and keeping its name is how a monitoring history quietly stops meaning anything. The primary anchor stayed where it was so the existing baseline remains comparable; the new anchors are recorded alongside it and will take over once they have accumulated enough history to have a baseline of their own.

Check your own

From any host you monitor, run a traceroute to whatever address your monitoring treats as "the internet." Then run one to a different well-known address operated by someone else. Compare the hop count and, more importantly, look for the latency step where traffic leaves your metro area. If your anchor's path has no such step, your reachability check is a local link test wearing a global label.

The test costs two commands. We did not run it for three months, which is the only reason this note exists.

Limitations

This is a single-day snapshot of one anchor from a handful of vantage points; anycast topology shifts, and the same address may behave entirely differently next month or from the next network over. We have not established why the Kyiv path terminates locally, only that it does. The correlation test described above covers one city and one anchor, and says nothing about network resilience in general - that question remains open precisely because our instrument could not answer it. We expect to be able to revisit it once the multi-anchor series has accumulated enough history.

All figures here come from our own distributed measurement network and are reproducible with standard ping and mtr from any host on the same networks.