Skip to content

What’s your ping
from around the world?

Ping any website, server or IP — 10 packets per route, with min / avg / max, jitter and packet loss graphed per location. ICMP blocked? Switch to a TCP handshake on any port.

14 locations · 14 countries · 6 continents jitter + packet loss, graphed per route Verdict in seconds
What a ping measures

Four numbers, one story

Every location fires 10 pings and reports the same four numbers. Together they tell you whether a route is fast, wobbly, or quietly eating packets.

RTT

Round-trip time — how long one packet takes there and back. We report min / avg / max of 10.

8 / 9 / 11 ms
JITTER

How much the ping wobbles between packets — what makes calls robotic and games rubber-band.

± 1.2 ms
LOSS

Pings that never came back. Above 1% on a wired route, TCP suffers and your users feel it.

0 / 10 lost
TCP

ICMP blocked? We ping the service itself — a real TCP handshake to :443 or any port you pick.

SYN → ACK 88 ms
Why multiple locations

One ping tells you almost nothing

Your server doesn’t have a ping — it has one per route. The same box answers in 8 ms from London and 220 ms from Sydney, and both numbers are correct.

One server, 14 vantage points 14 locations · 6 continents
Probe location — where your test pings from
Distance is physics

Light in fibre covers 200 km per millisecond. Los Angeles ↔ Sydney is 12,000 km — 120 ms round-trip before a single router queues you. A “slow ping” can be pure geography.

Loss patterns name the culprit

Packets dropping from one region only? A transit carrier on that path. Dropping from everywhere? The problem sits at your server’s doorstep. One location can’t tell those apart.

Ping ≠ bandwidth

Ping measures latency, not throughput. A gigabit line with 300 ms ping still feels slow — every click waits out the full round trip before the first byte moves.

When ping is blocked

No echo? Ping the service instead.

Plenty of hosts and clouds drop ICMP echo requests entirely — some cloud VMs do it out of the box. The result: 100% packet loss while the website loads fine. When that happens, switch the test to a TCP ping: a real connection handshake to the port your service lives on, timed to the millisecond.

  • Firewall-proof — ICMP may be filtered, but :443 has to be open
  • Per-service — web answering while the database port crawls? Now you know
  • Same math — min / avg / max, jitter and loss, from handshakes instead of echoes

ICMP vs TCP ping · example.com

from Cologne
ICMPecho request → reply · avg 89 ms10 / 10
:443TCP handshake (https) · avg 88 msopen
:80TCP handshake (http) · avg 88 msopen
:3306TCP handshake (mysql) · no answerfiltered
A filtered port isn’t an error — it means a firewall answers before the service does. Database ports should look like this from the public internet.
For terminal people

Prefer ping? Same test, 14 countries.

Strictly speaking you can’t ping a URL — ping talks to a host, so we strip the https:// for you. In the terminal, do the same — or let curl time the whole request:

Ping a website 10 timesMac/Linux ping -c 10 example.com
Same, on WindowsWin ping -n 10 example.com
Hunt packet loss — 100 rapid pingsping -c 100 -i 0.2 example.com | tail -2
“Ping” a URL — time it with curlcurl -o /dev/null -sw 'connect %{time_connect}s · total %{time_total}s\n' https://example.com
Test fragmentation — find the MTU limitLinux ping -M do -s 1472 example.com
Log a ping every second (script)while true; do ping -c1 example.com | grep time=; sleep 1; done
See which hop adds the latencymtr --report example.com
High ping? Packet loss?

Find out where the time goes

Six checks that separate “my Wi-Fi is bad” from “a carrier is dropping my packets” from “my server is drowning” — in the order worth trying.

Compare locations before you blame anything

One slow reading from your desk means nothing. If the test above shows 20 ms nearby and 300 ms far away, that’s geography — a CDN fixes it. Slow from everywhere? Keep reading.

Rule out your own last mile

Ping your router, then a public resolver, then your server — the hop where the number jumps is the culprit. ping 192.168.1.1 ping 1.1.1.1

Read packet loss the right way

One lost ping in 100 is noise. A steady 5% cripples TCP — pages stall, downloads crawl. And loss that only appears while you upload or stream is bufferbloat: re-run the test under load and compare.

Watch jitter, not just the average

For calls and games, a steady 60 ms beats 20 ms ± 40. The per-location graph shows the wobble — anything past ±30 ms is audible on a call.

100% loss but the site loads? That’s a firewall

ICMP is simply blocked — common and harmless. Switch the test to TCP :443: if the handshake answers, the server is fine and so is the route.

Slow from everywhere means server-side

An overloaded uplink, a saturated NIC, DDoS scrubbing in front — when all 14 routes degrade together, stop debugging the network and look at the host. This is the case monitoring catches at 3 a.m., before your visitors do.

FAQ

Common questions

Under 20 ms in the same region is excellent; under 100 ms feels instant for browsing. Gamers want under 50; for calls, jitter under ±30 ms matters more than the average. Past 150 ms, suspect distance before you suspect a defect — check the same route over time instead of comparing continents.

Not literally — ping addresses a host, not a page. Paste the URL anyway: we strip the scheme and path and ping the hostname behind it. If you want the full request timed (DNS, TLS, first byte, full load), that is curl territory — or our website availability test, which loads the page in a real browser from 30+ locations.

On a wired route the norm is 0.0%. At 1% you will measure slower TCP transfers; at 5% browsing is visibly broken and calls drop. Where it happens matters as much as how much: loss from one region points at a transit carrier, loss from everywhere points at the server's own connection.

Our probes sit in datacenters next to the big exchanges; you sit behind Wi-Fi, coax or 5G. Both numbers are true — ours isolate your server's routes, yours adds your last mile on top. If our 14 locations look clean but your ping is bad, the problem is between your chair and your ISP.

No — your host is blocking ICMP echo, which is common and deliberate. Re-run the test as a TCP ping to :443: it times a real connection handshake, which no web server can refuse. If that answers, everything is fine and the "loss" was a firewall doing its job.

Yes — paste any IPv4 or IPv6 address. Pinging a public resolver like 1.1.1.1 or 8.8.8.8 from 14 countries makes a neat baseline: they are anycast, so every region hits a nearby node and the numbers show what "good" looks like from each place.

Fourteen probes across 14 countries and 6 continents: Los Angeles and Toronto in North America; São Paulo and Lima in South America; London, Paris and Cologne in Europe; Istanbul, Tel Aviv, Mumbai, Singapore and Seoul across Asia; Sydney in Oceania; and Johannesburg in Africa. Each route is reported separately so you can see exactly where the latency or loss appears.

Free, no sign-up, no install — it replaces the ping utility you would otherwise download. The packets are standard echo requests and TCP handshakes, read-only and harmless. Uptimia earns its keep from monitoring subscriptions, not from this page.

Free tools are just the start.
Uptimia keeps your sites healthy.

Uptime, SSL, domain expiry, page speed, transactions — monitored from 171+ locations worldwide. Free for 30 days.

30 days free no credit card cancel anytime free plan after trial
100,000+ websites monitored · GDPR-compliant