Note · 11 November 2026

Why datacenter uptime monitors miss ISP blocks

An uptime monitor answers "does my server respond?". A block answers a different question: "does this provider let its customers reach my server?". The two only meet if the monitor stands where the customers stand.

Where European blocks actually live

Look at how the blocking regimes in our first three countries, and in Spain, are implemented:

• In Germany, the members of CUII, including Telekom, Vodafone, Telefónica (O2) and 1&1, block the sites it names in their DNS: most send visitors to a notice page, some answer that the site does not exist. (heise)
• In Poland, operators apply the CERT Polska warning list by replacing the DNS A record with the address of a warning page. (CERT Polska)
• In Norway, unlicensed gambling sites are blocked in providers' DNS since 1 January 2025. (Lotteritilsynet)
• In Spain, blocks during football broadcasts are applied to IP addresses inside access networks. (OONI)

Every one of these sits inside the access provider: its resolver, its routers. None of them is on the path between a cloud datacenter and your server.

What a datacenter monitor sees

A monitoring node in Frankfurt resolves your name with its hosting provider's resolver, or with a public one. It reaches your server over the hosting provider's transit. When Vodafone's resolver starts sending your name to a notice page, nothing on that path changes. The check stays green.

The same holds for most "check from 50 countries" tools: the countries are datacenter locations, not consumer networks. Censorship researchers have pointed this out for years. The ICLab platform, which used commercial VPN servers as vantage points, describes its results as only a lower bound on the censorship that individuals experience, and reports some evidence that datacenter networks block less aggressively than residential ones. (Niaki et al., IEEE S&P 2020)

Measuring from the subscriber side

To see what a provider's customer sees, the request has to leave from that provider's network and use that provider's resolver. Projects like OONI do this with volunteers who run a probe at home. For a site owner who needs an answer about one URL on one operator today, there are three practical problems:

1. Getting a vantage on the right network. Residential and mobile proxy networks have exits on most consumer ISPs, but their labels are unreliable. We select exits by network number and verify each one.
2. Keeping DNS on the subscriber side. Many proxy clients resolve the name locally and send an IP address to the proxy, which hides every DNS block. The name has to travel to the exit as a name.
3. Telling a block from a flaky exit. Exits drop and move. We bracket every measurement with an echo before and after and require several subscribers in several subnets before calling anything blocked. See how a check works.

What to do with this

Keep your uptime monitor: it answers its own question well. Add a provider-level check when your audience is concentrated in a few countries, when you sit on shared CDN addresses, or when a user report names a specific network ("doesn't open on Plus"). Those are the cases a datacenter cannot see.

Sources

1. heise online, "Copyright clearing house: Committee for website blocking to rely on judiciary", 16 July 2025.
2. CERT Polska, Lista Ostrzeżeń (warning list), wiedza.cert.pl.
3. Lotteritilsynet, Blokkering av ulovlige pengespillsider, lottstift.no.
4. OONI, LALIGA blocking report, 30 June 2026, ooni.org.
5. A. A. Niaki et al., "ICLab: A Global, Longitudinal Internet Censorship Measurement Platform", IEEE Symposium on Security and Privacy, 2020. arXiv:1907.04245.