Last updated: 2026-05-11
The gap we kept seeing
Every time we looked at where our monitors were firing from, and which regions were confirming outages, Southern Europe kept showing up as a problem.
We have agents across five continents: Singapore and Tokyo for Asia-Pacific, Johannesburg for Africa, São Paulo for South America, Chicago and Seattle for North America, and three agents across Europe - Portsmouth in the UK, Limburg in Germany, and Munich. That’s genuinely broad monitoring coverage.
But Southern Europe was the gap. Italy, Greece, the Balkans, and the Mediterranean coast are regions where a real outage could take longer to confirm simply because our agents weren’t close enough to matter.
We’ve been running quorum-based distributed monitoring for years. The system works. But the confirmation latency for Mediterranean targets was higher than I was comfortable with, and our detection confidence for that geography was thinner than I wanted.
So we fixed it.
Milan, Italy is now a live monitoring region. An agent is running inside Italy, checking endpoints from there, and participating in quorum decisions alongside our nine existing agents.
Why this is more than just “adding a location”
I want to be direct about something: adding a monitoring region is not a marketing bullet point. It’s not a checkbox in a feature race with competitors. It’s an engineering commitment that affects detection accuracy for every customer with infrastructure or users in that geography.
When a check runs from Milan instead of Munich, the response time data is more representative of what an Italian user actually experiences. A confirmation burst for a Mediterranean outage reaches quorum faster. A routing problem localized to Italy gets detected by a Milan agent, not inferred from three other regions that might see it as a slow response rather than a failure.
This matters because the goal of distributed monitoring is to eliminate blind spots, and blind spots don’t just cost you detection speed. They cost you accuracy. And accuracy in monitoring is everything.
A false positive is a distraction. A missed outage is a crisis. Getting both right requires geographic distribution that reflects where your users actually are, not just where your engineering comfort zone is.
What we actually shipped
Milan joins our existing global monitoring network:
| Region | Flag | Code | Geography |
|---|---|---|---|
| Singapore | 🇸🇬 | apac-se-sg | Asia-Pacific - Southeast |
| Tokyo | 🇯🇵 | apac-east-jp | Asia-Pacific - East |
| Johannesburg | 🇿🇦 | af-south-za | Africa - South |
| São Paulo | 🇧🇷 | sa-east-br | South America - East |
| Portsmouth | 🇬🇧 | eu-west-uk | Western Europe |
| Limburg an der Lahn | 🇩🇪 | eu-central-de | Central Europe |
| Munich | 🇩🇪 | eu-south-de | Central Europe (primary) |
| Milan | 🇮🇹 | eu-south-it | Southern Europe |
| Chicago | 🇺🇸 | na-central-us | North America - Central |
| Seattle | 🇺🇸 | na-west-us | North America - West |
Ten regions. Five continents. Every region runs every check type: HTTP, TCP, DNS, keyword, database, heartbeat, SSL, and email authentication.
All plans with multiple monitoring locations include Milan. If you use our default region selection, Milan is already part of your monitoring mesh where it improves coverage. If you manually configure regions, you can add Milan from your monitor settings using Per-Monitor Regions.
Paid plan users can also select Milan as their primary monitoring server; your checks originate from Milan first, with secondary confirmation from other regions within 20 seconds. Learn how to change your primary region →
Why geographic coverage keeps me up at night
I’ll close with something honest.
Monitoring infrastructure is one of those things that looks solved from the outside: you ping an endpoint, you get a result, the math seems simple. But the hard part is not the ping. The hard part is the detection problem: knowing the difference between “this endpoint is actually down” and “this endpoint is responding slowly because something in the network is acting up.”
That problem gets harder the further your monitoring agents are from the endpoints they’re checking. Latency variance, routing asymmetry, and regional internet backbone issues can all look like failures when they’re not, or mask real failures when they are.
The only way to reduce that uncertainty is to have agents close enough to the infrastructure you’re checking that latency variance becomes noise, not signal. Milan is our answer to that problem for Southern Europe.
It’s also the reason we keep evaluating new regions. Not because competitors have more, but because every region we add is a bet that geographic distribution matters, and that the monitoring industry has been underselling the importance of detection accuracy for too long.
If you haven’t reviewed your monitor region settings recently, spend five minutes on it. If you need one service to use Milan without changing the rest of your account, start with Per-Monitor Regions. Milan is live. Your Mediterranean users are counting on it.
Questions about regions, primary servers, or anything else? Talk to us.
