API Accessibility from Different Countries: 5 Metrics Visible Only to External IP

If your API monitoring is running on a server in one data center, you only see part of the picture. A user in Brazil may receive a 500 error while your dashboard in Moscow shows a green "all systems operational" status. Let's explore which 5 availability metrics cannot be measured without a request through a real external IP from another country, and how to do this without complex infrastructure.

Why Local Monitoring is Misleading

Most teams set up API monitoring through UptimeRobot, Pingdom, or their own cron script that pings the endpoint once a minute. The problem is that these requests almost always come from one or two regions — usually from the US or Europe, where the monitoring service servers are located. If your audience is in India, Brazil, or Southeast Asia, local providers may throttle traffic, a CDN node may be overloaded, and DNS may resolve to an outdated IP.

Another common scenario is geo-blocking at the CDN or WAF level (Cloudflare, Akamai). Some security rules block entire ranges of IPs from certain countries, making your API physically unavailable to some users, even though everything works perfectly from your office IP. Such issues cannot be diagnosed if testing is done from only one point.

A third scenario is load balancing through Anycast or regional CDN edges. A request from Germany may hit one node, while one from Singapore may hit a completely different one, with a different cache version or configuration. Differences in API behavior between regions are not theoretical; they are what teams regularly encounter when their users are distributed globally.

5 Availability Metrics Visible Only Through External IP

Below are five metrics that show the real picture of availability only when the request is made from an IP address physically located in the target country or at least routed through its network.

1. Response Time (Latency / RTT)

Round-Trip Time is the time from sending a request to receiving the first packet of response. From one server in Europe, the latency to your API may be 20 ms, while a user from Southeast Asia may wait 400-600 ms due to geographical distance and the number of intermediate hops. If latency is not measured from different regions, it is easy to miss the moment when the service becomes practically unusable for part of the audience — especially critical for APIs tied to real-time operations: bidding in advertising, chats, fintech transactions.

2. TTFB (Time To First Byte)

TTFB shows how long the server processes the request before it starts sending the response. This metric depends not only on the network but also on which CDN or load balancer node serves a specific region. It often happens that an edge server in one country caches the response and delivers it in 50 ms, while in another country, the request always reaches the origin server and is processed anew, taking 800 ms or more. Differences in TTFB between regions are a sure sign of configuration issues with the CDN or insufficient coverage of edge nodes.

3. DNS Resolution Time

DNS resolution is a separate source of delays and errors that completely depends on the user's local resolver. If you have GeoDNS configured (different A records depending on the request region), a configuration error may lead to users from one country resolving to a data center on another continent — with huge delays. This issue is only visible when requesting DNS resolution from a real IP of the target country; a local test will always resolve "correctly" relative to your own geolocation.

4. Percentage of Successful Requests (Uptime) by Region

An uptime of 99.9% on a monitoring dashboard that pings from one point does not guarantee 99.9% for users in another country. Local providers may have peering issues specifically to your hosting provider, resulting in some requests from country X timing out while the rest of the world does not notice the problem at all. To see the real uptime, you need to count successful and unsuccessful requests separately for each region, not aggregated.

5. Differences in Content and Status Codes (geo-blocking and personalization)

The fifth metric is not about speed but about the content of the response itself. An API may return a 403 Forbidden for certain countries due to WAF rules, return a reduced dataset due to licensing restrictions, or show a different version of content due to A/B tests tied to geography. If you test the API only from your IP, such differences will go completely unnoticed — and they are often the cause of complaints from users in specific regions.

How to Set Up Monitoring from Different Countries

The logic of the setup is simple: you send the same HTTP request to your API from multiple points simultaneously, record all five metrics, and compare the results. Step by step, it looks like this:

1. Compile a list of priority countries — usually the top 5 countries by traffic volume or revenue.
2. For each country, prepare an exit point with a real IP from that country (proxy server or physical server).
3. Set up a script or service that sends identical requests through each point at a specified interval (e.g., every 5 minutes).
4. Log all 5 metrics separately for each country in a database or metrics system (Grafana, Prometheus, ClickHouse).
5. Set up alerts for metric deviations from the baseline — for example, if latency from a specific country increases threefold over an hour.

The key point is item 2. Without a real exit to the required country, all other steps are meaningless because the metrics will measure not what the user sees, but what your own monitoring server sees.

Which Type of Proxy to Choose for Monitoring

For building geographically distributed monitoring, proxy servers are most often used — they are cheaper and faster than renting physical servers or VPS in each required country. The choice of proxy type depends on what exactly you want to measure.

Proxy Type	When to Use	Features
Data Center Proxies	Basic availability and latency checks when real user simulation is not needed	High speed, low cost, but IP is easily identified as data center — not suitable for testing geo-blocking by providers
Residential Proxies	Checking what a real user sees with a home provider	IP belongs to real providers in a specific country, reflecting routing and WAF rules more accurately
Mobile Proxies	Testing API availability for mobile applications and mobile traffic	IP from mobile operator networks, shows delays and blocks specific to mobile traffic

If your API primarily serves web traffic from desktops and servers, data center proxies are sufficient for basic monitoring — they provide stable speed and predictable latency. However, if you need to check exactly what a real user encounters — including geo-blocking rules set by the provider's ASN — it is worth using residential proxies, as they are routed through the networks of ordinary internet providers in the same country. For mobile applications and SDKs that make requests to the API, it makes sense to add checks through mobile proxies, as mobile operators often use NAT and their own routing rules that differ from home internet.

Ready-made Python Script for Collecting Metrics

Below is a simplified example of a script that sends a request through a proxy in a specified country and collects four out of five metrics (content differences need to be compared separately by matching responses). The script uses the requests library and the socket module to measure DNS resolution time.

import time
import socket
import requests

def measure_api(url, proxy, country_label):
    hostname = url.split("//")[1].split("/")[0]

    # 1. DNS resolution time
    dns_start = time.time()
    try:
        socket.gethostbyname(hostname)
    except socket.gaierror:
        pass
    dns_time = time.time() - dns_start

    proxies = {
        "http": proxy,
        "https": proxy,
    }

    try:
        start = time.time()
        response = requests.get(
            url,
            proxies=proxies,
            timeout=10,
            stream=True
        )
        ttfb = time.time() - start  # approximate TTFB

        full_load_time = time.time() - start
        status_code = response.status_code
        success = status_code == 200

        result = {
            "country": country_label,
            "dns_time_ms": round(dns_time * 1000, 2),
            "ttfb_ms": round(ttfb * 1000, 2),
            "total_time_ms": round(full_load_time * 1000, 2),
            "status_code": status_code,
            "success": success,
        }
    except requests.exceptions.RequestException as e:
        result = {
            "country": country_label,
            "dns_time_ms": round(dns_time * 1000, 2),
            "ttfb_ms": None,
            "total_time_ms": None,
            "status_code": None,
            "success": False,
            "error": str(e),
        }

    return result


# Example usage with proxies from different countries
endpoints = [
    {"label": "Germany", "proxy": "http://user:[email protected]:port"},
    {"label": "Brazil", "proxy": "http://user:[email protected]:port"},
    {"label": "Singapore", "proxy": "http://user:[email protected]:port"},
]

API_URL = "https://api.yourservice.com/health"

for ep in endpoints:
    data = measure_api(API_URL, ep["proxy"], ep["label"])
    print(data)

For a production version of such a script, it is advisable to add result logging to a database (e.g., ClickHouse or InfluxDB), visualization through Grafana, and alerts via a Telegram bot or Slack webhook when threshold values are exceeded. It is best to run the script via cron or a task scheduler at intervals of 5-15 minutes for each country.

If you need a quick check without writing code, a similar request can be made via cURL with time measurement:

curl -x http://user:[email protected]:port \
  -o /dev/null -s -w "DNS: %{time_namelookup}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s | HTTP: %{http_code}\n" \
  https://api.yourservice.com/health

How to Interpret the Results

After collecting data from all countries for at least a week, a baseline for each region emerges. Next, you need to look not at absolute figures but at deviations from this baseline. If latency from Brazil consistently holds at 350 ms — that is normal for the geography, and an alert should be raised if the value suddenly rises to 1500 ms. Similarly with uptime: 99.5% for a challenging region with unstable internet may be an acceptable norm, while a drop to 95% could signal a problem on the provider's or CDN's side.

Special attention should be paid to status codes 403 and 451 — they almost always indicate geo-blocking by WAF or CDN, rather than a problem with the API itself. If such codes appear only from a specific country and only when using a certain type of proxy (e.g., data center), it may mean that the blocking is set based on the criterion "IP looks like a data center" rather than actual geolocation — in this case, testing with residential proxies will provide a more honest picture.

Ready-made Services vs Custom Solutions

If you don't want to maintain your own script, there are ready-made synthetic monitoring services with points of presence in different countries: Pingdom, Uptrends, Site24x7, Checkly. They eliminate the need to set up infrastructure but are usually limited to a fixed set of locations and do not offer flexibility in choosing the type of IP (residential, mobile, data center) for a specific test.

A custom solution based on proxies provides more control: you can test exactly the countries that are important for your business, switch between IP types to diagnose specific issues (e.g., geo-blocking by ASN), and integrate metrics directly into your monitoring system without unnecessary intermediaries. A combination of both approaches is a reasonable balance: ready-made services for basic SLA monitoring, and a custom script with proxies for pinpoint diagnosis of problems in specific regions.

Conclusion

Local monitoring from one point shows only part of the truth about API availability. To see the real picture, you need to measure latency, TTFB, DNS resolution time, uptime, and content differences separately for each country — and do this through an IP that is actually routed through the network of the target region. Without this, it is easy to miss a problem that prevents part of the users from using the service while the dashboard shows "all green."

For building such monitoring, residential proxies are the best fit if it is important to see the same thing that a real user with home internet in a specific country sees. For a cheaper and faster basic availability check, data center proxies will suffice, while for diagnosing issues specifically for mobile audiences, it is advisable to add checks through mobile proxies. This combined approach provides a complete picture of how your API looks from anywhere in the world, not just from the server where it is deployed.