Uptime and latency monitoring from datacenter cities

Why monitor from datacenter cities?

Monitoring from datacenter cities shows how your service behaves from the network hubs your users' traffic passes through. A check from your office only tests one path. A check from Frankfurt, Singapore or São Paulo tests the route, DNS answer and CDN edge served to that region.

Typical questions it answers:

• Does the site answer from every market, or does one region get errors?
• Does the CDN send Tokyo visitors to an Asian edge, or all the way to Virginia?
• Did a DNS or certificate change reach every region?
• Is a slow page a server problem or a distance problem?

A datacenter IP measures the datacenter path, not a home user's last mile over Wi-Fi or mobile. That is a feature for repeatable checks, and a limit if you need real-user timings.

What is the minimum latency between two cities?

The minimum round trip in milliseconds is about the distance in kilometers divided by 100. Light in optical fiber travels about 200 km per millisecond, and a round trip covers the distance twice. Real routes are longer than a straight line, so measured values are higher.

The nearest pairs among our datacenter city pages, from the distances on those pages:

If a check from Amsterdam to a London server takes 40 ms, distance explains under 4 ms of it; look at routing, TLS setup or the server. The city data table lists every city with its facilities and nearest neighbor.

How does a proxy change what I measure?

A proxy adds a leg to every request: your checker talks to the proxy, and the proxy talks to your service. The total time is the sum of both legs, so a checker in Paris using a Tokyo IP mostly measures Paris to Tokyo.

Two clean ways to read the numbers:

1. Run the checker near the proxy. A small server in the same region keeps the first leg short, so the timing reflects the city you chose.
2. Measure the first leg separately. Time a request to a light endpoint through the proxy and subtract that baseline from your service timing.

For uptime alone, the extra leg does not matter: the question is whether your service answers from that city at all, and with which status code and content.

# Documentation address; use an IP, port and credentials from your account
curl -x http://USERNAME:[email protected]:8000 \
  -o /dev/null -s \
  -w "status=%{http_code} connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" \
  https://example.com/health

How do I build a simple multi-city monitor?

A simple multi-city monitor needs one IP per region, one health URL on your side and a scheduler.