Is it down, or is it just you?
A multi-vantage check runs the same test — a ping, an HTTP request, a DNS lookup — from probes on other people’s networks, in other countries, at the same moment you run it from yours. That one change turns an unanswerable question (“works for me — is anyone else seeing this?”) into a comparison: if every vantage point fails, the target is down; if only yours does, the problem lives on the path between you and it. This guide explains what a second vantage point actually proves, the anycast caveat that catches everyone once, and how to run the check with the global ping on this site.
The works-for-me problem
Every incident channel has heard both sentences in the same hour: “the site is down” and “works for me”. They can both be honest reports. A test run from a single vantage point — your laptop, your office, one monitoring box — measures exactly one thing: the experience of that one network, on that one path, at that one moment. It cannot distinguish a service that is down for everyone from a path that is broken only for you: a sick transit provider, a regional filtering rule, a DNS resolver returning poisoned or stale answers, a peering dispute three networks away that you have never heard of. From inside the single viewpoint, all of these look identical — a failure with no return address.
Support tickets and status pages suffer from the same geometry. A status page says “operational” because the provider’s own probes — sitting in the provider’s own neighbourhood — reach the service fine, while a whole region cannot. A user reports “down” because their ISP is black-holing the traffic, while the service hums. Neither side is lying; both are generalising from one chair. The fix is not more precision from the same chair. It is more chairs.
What a second vantage point proves
Add probes on other networks — other autonomous systems, other countries, other kinds of connection — and run the identical test from all of them at once. Now the pattern does the arguing. If probes on five networks across three continents all fail the same way at the same time, the common factor is the target: the service, its host, or its own network is down, and no amount of local fiddling will change that. If four succeed and only the probe nearest your situation fails — or only you fail — the common factor inverts: the target is up, and the break is somewhere on the path the failing viewpoints share. Agreement across independent vantage points is the closest thing “is it down?” has to a proof.
The probes this site uses belong to the Globalping network, run by jsDelivr: thousands of small software probes hosted by volunteers all over the world, on everything from data-centre servers to home connections, which accept standardised measurements — ping, traceroute, MTR, DNS and HTTP — and report back what they saw. The value is not any single probe; a volunteer box in one city is an anecdote. The value is that the anecdotes are independent: different networks, different upstreams, different failure modes, all answering the same question at the same time.
The anycast and CDN caveat
Here is the trap, and everyone falls into it once: different answers from different places can all be correct. Modern services are not one machine in one place. Anycast announces the same address from many locations, so a probe in Frankfurt and a probe in São Paulo sending packets to “the same” IP are talking to different physical edges, possibly on different continents of infrastructure — one healthy, one rebooting. A CDN steers each client to a nearby edge, and an edge can be down in one region while the service is flawless elsewhere. Divergence between probes is not automatically contradiction; for an anycast target, divergence is the design working as intended, and the question becomes “down where?” rather than “down?”.
DNS makes the same point from the other side. Authoritative servers and resolvers hand out different answers by design — GeoDNS returns the address of the “nearest” edge, and EDNS Client Subnet lets a resolver ask on behalf of your neighbourhood, so a probe’s resolver in Tokyo and one in Texas legitimately receive different addresses for the same name (compare them side by side with the DNS propagation checker when the question is which records the world holds). Different addresses from different probes are not evidence of inconsistency. They are evidence the name is doing localisation — and they tell you which edge each region’s users will actually meet.
Pick the measurement that answers the question
The global ping offers five measurement types, and choosing well matters more than running many. Each answers a different question, and running the wrong one produces a confident answer to something you did not ask. Match the type to the symptom before you look at anyone’s results.
Ping answers the narrowest question: is the target reachable from here, and how much is lost on the way? It is the right test for “can this network see that host at all”, and the wrong test for anything about the application — a host can answer ping while its web service is dead. HTTP answers the user’s question: does an actual request succeed from there, with what status code, and how long did the whole thing take? When the argument is “the site works / the site doesn’t”, HTTP from several probes is the evidence both sides should accept. DNS answers the naming question: which addresses does each region actually get for this name? It is how you separate “the service is down” from “my region is being sent to the dead edge”.
Traceroute answers the where question: hop by hop, where does the path from this probe to the target stop, stall, or veer somewhere unexpected? Run it from the failing vantage point, not from one that works. MTR is traceroute over time — the same path probed repeatedly, so loss and delay show per hop as rates rather than as one frozen sample; it is the tool for “it breaks intermittently”, where a single traceroute catches the path on a good behaviour day. The discipline across all five: decide which failure you are testing for, pick the one measurement that can see it, and let the others wait.
Reading results without fooling yourself
Start by separating the two numbers people habitually merge. Loss — requests that never came back — is damage; latency — requests that came back slowly — is discomfort, and the two have different causes and different fixes. A probe showing 100% loss has found a wall; a probe showing no loss and high latency has found a long or congested road, and reporting the second as “down” is how healthy services get paged. Then compare like with like: take the median probe as the story, not the best and not the worst. One probe returning a wild outlier — enormous latency, a timeout nobody else saw — is a statement about that probe’s moment, its host, or its upstream. It becomes evidence about the target only when independent probes agree with it.
Mind the bookkeeping, too. One probe that reports the target “offline” while its neighbours succeed has most likely reported itself — a crashed probe, a home connection that dropped, a local filter — and volunteer probes have all of these; that is the price of a network nobody centrally operates. Note the timestamps and treat stale or cached results as history, not news. And when every probe agrees the target is up but your users still cannot reach it, believe both: you have learned the failure is real and narrow — it lives on a path none of your probes happened to share, which is a finding, not a contradiction.
Honest limits
The probes are volunteers, and the network behaves like it. Probes come and go — a location available this morning may be offline tonight, coverage is dense in some countries and thin to nonexistent in others, and you cannot demand a probe inside a specific ISP just because that is where your users are. The probes also sit mostly in data centres and on enthusiast connections, not on the residential and mobile networks your actual users browse from; a data-centre probe proves the service is reachable from well-connected places, which is most of the question, but not the whole of it. Treat the map as a sample of the world’s networks, drawn generously — not as the world.
This site’s use of the network is deliberately modest: it runs on Globalping’s anonymous, shared free tier, so checks carry per-visitor limits and results are briefly cached rather than hammering a volunteer resource — if a check asks you to wait, that is the shared tier being shared. Within those limits, the working pattern is: run the multi-vantage check here to settle “down or just me”, then go deeper on the winner — the website health check for everything a single detailed look at the site can tell you, and a fresh round from the global ping once you have changed something. Down-for-everyone and down-just-for-you need different afternoons; ten minutes of other people’s vantage points is how you find out which afternoon you are having.
Frequently asked questions
How many locations should I test from?
This tool runs up to four locations per check, and four chosen well beat forty chosen at random. Pick a spread that matches the argument: one probe near your own users, one on another continent, one near the target’s hosting, and one anywhere distant as a control. If the near and far probes agree, you have your answer; if only the near ones fail, you have also localised the problem. More locations mainly help when the first four disagree in a pattern you cannot yet read.
A probe says offline — is the site down?
Not on that evidence alone. A single probe can be offline itself — crashed, disconnected, or behind a filter of its own — and volunteer probes have no operator guaranteeing them. “Down” is a conclusion you draw from agreement: several independent probes, on different networks, failing the same way at the same time. One probe failing while its neighbours succeed tells you about that probe’s path, and the honest report is “unreachable from that one vantage point”, not “down”.
Why does the same domain resolve to different addresses from different probes?
Because that is how it is supposed to work. GeoDNS and EDNS Client Subnet let DNS answers depend on where the query appears to come from, so each region is handed the address of its nearest healthy edge; anycast and CDNs rely on the same trick at the routing layer. Different addresses from different probes are the localisation doing its job. It only becomes a finding when one region’s address is dead while the others work — then the name is faithfully sending that region’s users to a broken edge.