French 
English 
Your site is up. You just looked at it.
That statement is true and almost useless, because what you actually confirmed is that your site was reachable from one machine, on one network, in one country, at one moment. Your visitors are not on that machine. Some of them are 8,000 kilometres away, routed through a different set of networks, hitting a different CDN edge node, and resolving your domain through a different DNS server.
Availability isn’t a single yes or no. It’s a map, and most site owners only ever see one pixel of it.
Uptime and availability are not the same thing
The two words get used interchangeably and they shouldn’t be.
Uptime is a measurement over time: what percentage of the last 30 days was the server responding. Availability is a measurement over conditions: can people actually reach and use the site, from where they are, right now. A server with 99.99% uptime can still be unavailable to an entire country because of a routing problem or a regional CDN failure, and that failure will barely register in the uptime figure.
The gap between them is where the frustrating incidents live. Support gets three complaints, you check the site, it works, you close the tickets. Then twenty more arrive.
What the nines actually cost you
Everyone quotes uptime percentages. Fewer people translate them into time, which is where they stop sounding abstract:
| Uptime | Downtime per month | Downtime per year |
|---|---|---|
| 99% | ~7 hours 18 min | ~3.65 days |
| 99.5% | ~3 hours 39 min | ~1.83 days |
| 99.9% | ~43 minutes | ~8.76 hours |
| 99.95% | ~22 minutes | ~4.38 hours |
| 99.99% | ~4 minutes 23 sec | ~52.6 minutes |
| 99.999% | ~26 seconds | ~5.26 minutes |
99% sounds respectable in a sales deck. It’s three and a half days offline a year. Most shared hosting SLAs promise 99.9%, which still allows nearly nine hours annually, and the SLA typically only pays out in hosting credit anyway. Credit for a month of hosting does not cover a lost weekend of sales.
There’s also a measurement question hiding in every one of these numbers: uptime according to whom. A host measuring from inside its own data centre will report figures that look nothing like what your customers in another hemisphere experience.
Why a site is up in one place and down in another
Several failure modes are regional by nature.
CDN edge failures. Your content is served from dozens or hundreds of edge locations. When one has a problem, visitors routed to it get errors while everyone else is unaffected. This is one of the most common sources of “some of my users say it’s broken.”
BGP routing problems. The internet’s routing system occasionally sends traffic down a broken or hijacked path. Your server is fine. Certain networks simply can’t find it.
Regional cloud incidents. Cloud providers fail by zone and region, not globally. If your infrastructure or a dependency lives in the affected region, that region’s users notice and nobody else does.
DNS inconsistency. After a nameserver change, different resolvers around the world update at different rates. For a window that can stretch across a day or more, some visitors get the new IP and some get the old one.
Undersea cable cuts and ISP failures. Cloudflare’s own quarterly outage reporting regularly documents these. A single fibre cut near Saint Lucia in June 2026 dropped that country’s overall internet traffic by roughly 60% for close to a day. Nothing was wrong with any of the sites involved.
Country-level blocks and firewall rules. Sometimes deliberate, sometimes an overzealous WAF rule that banned an entire IP range because one address on it misbehaved.
Notice that in most of these, nothing is wrong with your server. Which is exactly why a check from a single location keeps reporting green.
Latency is an availability problem too
A site that takes eleven seconds to load in Sydney is, functionally, down for people in Sydney. They leave before it renders. Your monitoring records a 200 and files it under “up.”
Round trip time is bounded by physics. A request from Karachi to a server in Virginia has a floor of roughly 200ms before your application does anything at all, and every additional round trip for DNS, TLS handshake, and asset loading multiplies that floor. Add an unoptimised page and you have a site that feels broken to half your audience while looking perfect to you.
This is why response time belongs in the same conversation as uptime rather than in a separate performance bucket. If you only ever measure whether the server answered, you’ll miss the slow degradation that precedes most outages and the geographic slowness that never becomes an outage at all but costs you conversions anyway. A proper speed test and ongoing performance monitoring fills in what a binary up/down check leaves out.
Building a check that reflects reality
A few decisions determine whether your monitoring tells you the truth.
Test from where your users are. If 40% of your traffic is European, a US-only check is measuring the wrong thing. Match your probe locations to your analytics, not to where your server sits.
Require agreement before you alert. One location reporting a failure is frequently the location’s problem. Two or more agreeing is a real incident. This single rule eliminates most false alarms, and false alarms are how monitoring becomes background noise people ignore.
Check every minute or two for anything transactional. Your check interval is your worst-case detection time. A 30-minute interval means a 29-minute outage can happen entirely unobserved.
Monitor paths, not just the homepage. Login, search, checkout, and any API your mobile app depends on can each fail independently while the front page stays perfect.
Alert on response time thresholds, not only on failures. Slowness is the early warning. A site that drifts from 700ms to 4 seconds is usually an hour or two from becoming a 504.
Keep the history. Without a record you can’t tell your host “this is the fifth time this month,” and you can’t tell whether things are improving. The log is also what turns a vague complaint into a specific one, which is what gets support tickets escalated.
If you’re setting this up from scratch, it’s worth understanding the different types of website monitoring and what each one catches before configuring anything, because the categories overlap and it’s easy to end up with three checks that all test the same thing.
What worldwide availability data is good for
Beyond alerting, the data itself answers questions you otherwise argue about.
It tells you whether a CDN is earning its cost, because you can see whether response times outside your home region actually improved after you added it. It gives you evidence when a host claims their platform was fine and your logs say otherwise. It shows whether the migration you did last month made things better or just moved the problem. And it tells you which regions are worth optimising for, which is a different question from which regions currently send you traffic, because slow markets underperform and then look unimportant in analytics as a result.
That last point is a genuine trap. A region that loads badly converts badly; converts badly means low revenue; low revenue means it looks like a market that doesn’t care about your product. The data is describing a technical problem and you read it as a demand signal. The broader business case for treating uptime and availability as a revenue metric rests largely on this kind of feedback loop.
99.9% is the standard baseline and what most hosting SLAs promise, allowing about 43 minutes of downtime per month. For ecommerce or anything transactional, 99.95% or better is a more sensible target. Chasing 99.999% is rarely worth the cost outside of infrastructure that other businesses depend on, since the engineering effort rises far faster than the returns.
Most commonly a CDN edge node failure, a BGP routing issue, a regional cloud incident, or DNS records that haven’t propagated evenly. Less commonly it’s deliberate: a country-level block, or a firewall rule that banned an IP range containing your visitors. Testing from several locations at once is the fastest way to see the shape of the problem.
Every one to five minutes for anything where downtime costs money, since the interval sets your worst-case detection delay. Every 15 to 30 minutes is fine for a personal site or blog. Checking more frequently than once a minute rarely adds value and can trigger rate limiting on your own server.
Brief outages generally don’t. Google retries and treats short 5xx responses as temporary. Sustained downtime is different: if crawlers hit errors repeatedly over days, crawl rate falls and pages can drop from the index. During planned maintenance, return a 503 with a Retry-After header, which tells crawlers to come back rather than suggesting the page no longer exists.
Uptime monitoring asks whether the server responded. Performance monitoring asks how long it took and what the visitor experienced. A site can pass every uptime check while being unusable in half the world because pages take ten seconds to render. The two answer different questions and neither substitutes for the other.
The short version
Availability is geographic. Uptime measured from one place is a partial answer that occasionally becomes a wrong one.
Check from more than one location, watch response time alongside status, and keep the history so you can tell whether anything is actually getting better.