Global Ping
Global ping runs one measurement — ping, HTTP, DNS, traceroute or MTR — from probes in networks around the world at the same time, so you can see whether a problem is everywhere or only on your path. Pick a measurement, name a target, choose up to four places, and compare the answers side by side.
Want this watched from many places around the clock? Monitor this free with myeventwatch — expiry and downtime alerts, no card required.
One measurement, many vantage points
Every network test you run from your own desk answers a narrower question than you think: not “is this host up?” but “is this host up from here, along my provider, through my peering, right now?”. The internet has no single point of view, and most confusing outages are local in a way that is invisible from inside them — a broken route in one region, a poisoned resolver in one country, an anycast node failing for one continent while happily serving another. Global ping removes your own path from the equation by running the identical measurement from volunteer probes in unrelated networks at the same moment. When every probe agrees the target is down, the target is down. When one city fails and the rest sail through, the problem lives on a path, not at the destination — and that single distinction is usually half the debugging battle.
The five measurements answer different follow-ups. Ping gives round-trip time and packet loss, the raw health of reachability. HTTP times a real request and returns the status code, catching the large class of failures where a host pings fine but the service on it does not work. DNS asks each probe’s local resolvers, which is how you catch an answer that is correct in Frankfurt and wrong in Singapore. Traceroute lists the hops from the probe to the target, so you can see where paths diverge. MTR combines the two, pinging every hop repeatedly, which separates “the last hop is slow” from “one middle link drops packets and everything after it merely inherits the blame”.
How to read a split result
Start with agreement. If all probes report similar times and the same answers, your own problem is almost certainly between you and the wider internet — your provider, your VPN, or your local resolver. If exactly one location disagrees, suspect geography: routing is per-network, and a single transit provider’s bad path can blackhole one region while leaving everyone else untouched. If the DNS answers differ by location for a name that is not deliberately geo-steered, that is a fault, not a feature — resolvers should converge on the same records once caches expire. And when a target resolves to different addresses in different places on purpose, you are looking at anycast or geo-DNS working as designed: compare each probe against the address it actually reached, which this page prints, rather than expecting one true answer.
Related tools: the website health check for the full picture of one site from sysosx’s server, the DNS propagation checker for whether four big public resolvers agree on a name, and the companion article is it down, or is it just you? on using many vantage points to settle exactly that question.
Attribution and honesty: measurements run on the Globalping network by jsDelivr, executed by volunteer-run probes hosted in networks around the world — please treat the network as the shared resource it is. This page uses the shared free tier, so per-visitor limits apply, popular targets are cached briefly, and at busy moments the upstream itself can be saturated, which the page reports rather than disguising as a target failure.
Five terms that make the results readable
| Probe | A small agent running in someone else’s network — a home connection, a cloud VM, a university — that performs the measurement where it sits and reports the result. |
| Vantage point | Where a measurement is taken from; the same target can look healthy from one vantage point and broken from another, and both observations can be true. |
| Anycast | Announcing the same IP address from many places at once, so each user reaches the nearest instance — which is why different probes legitimately reach different machines at one address. |
| Packet loss | The share of packets sent that never come back; a little loss on a long path is survivable, sustained loss means something on the path is dropping traffic. |
| MTR | A hybrid of ping and traceroute that pings every hop on the path repeatedly, showing loss and latency per hop instead of only at the destination. |
Frequently asked questions
Why do locations have to be typed in English?
The Globalping API matches location names against its own English gazetteer of cities, regions and countries. “Frankfurt”, “New York” and “Singapore” match reliably; a translated city name usually matches nothing, and the measurement cannot start. The four boxes are therefore labelled honestly: type the place in English, and use the suggestions list, which offers ten well-covered cities. One probe is selected per location you name.
A probe says offline or failed. Is the target down?
No — that result is about the probe, not the target. A probe can go offline, lose its own connectivity, or be unable to run a particular measurement type; the remaining probes’ results still stand. Judge the target by the probes that finished: if they agree, their verdict is the answer, and a single failed probe is noise about the measurement network itself.
Why are the results sometimes cached, and why the limits?
Measurements consume a shared, volunteer-run network on a free tier with a modest hourly budget shared by everyone using it through this site. To keep that fair, each visitor gets a limited number of fresh measurements, and repeating the same measurement within a short window returns the cached copy, labelled as such. If the upstream free tier itself is exhausted, the page says so plainly instead of inventing a result.
Ping works but HTTP fails (or the reverse). What does that mean?
They test different layers. Ping proves the host’s network stack answers ICMP; it says nothing about the web server, which may be down, misconfigured, or returning errors — an HTTP result with a 5xx code is a working network and a broken service. The reverse — HTTP works, ping times out — is also common and usually innocent: many hosts and firewalls deliberately drop ICMP while serving traffic normally.
Can I test from more than four locations, or run this continuously?
This page runs up to four probes per measurement to stay within the shared free tier. For continuous checking from many places — the “wake me when it breaks anywhere” version of this tool — a monitoring service is the right shape; the link under the form offers free monitoring through myeventwatch. For a one-off question, four well-spread locations are usually enough to separate “down everywhere” from “down only for some”.