Ping
ICMP echo request — round-trip time, jitter, packet loss.
No result yet
Enter the inputs above and press Run. Results appear here in a moment.
Monitor this 24/7 — get alerts on the first failure.
Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our Terms.
What is Ping?
Ping is the most basic reachability check on the internet: send an ICMP echo request, see if you get an echo reply back, measure how long it took. When something "can't be reached" — a server, a printer, a customer's site — ping is the first question. Is it network-level down, or is the higher layer broken?
This tool runs the standard ICMP ping sequence against any public IP or hostname and gives you the four numbers everyone wants: round-trip time (min/avg/max), jitter, packet loss percentage, and whether the host actually replied. It runs from a real server with real network egress, not from your browser (browsers can't send raw ICMP — pings that "run in your browser" are usually HTTP requests in disguise).
How it works
Each ping run is a small sequence of ICMP packets:
- 1Resolve hostname if needed — If you typed a hostname, we do a quick DNS lookup first to find the target IP. If you typed an IP, we skip resolution.
- 2Send N ICMP Echo Request packets — Default 5 packets, configurable up to 20. Spaced 200ms apart (to avoid hammering the target). Each packet is 56 bytes of payload + 8 bytes ICMP header + 20 bytes IP header — 84 bytes on the wire.
- 3Wait up to 2s per packet for reply — Each ICMP Echo Request includes a unique sequence number. The target's kernel auto-replies with an ICMP Echo Reply carrying the same sequence number. We match replies to requests by sequence and record the round-trip time.
- 4Aggregate and report — Min/max/avg RTT across replies received. Jitter = standard deviation of RTT. Packet loss % = (sent - received) / sent. If zero replies received, we report 100% loss + the most likely reason (timeout, destination unreachable, no route).
When you'd use it
"Is the server down or is my app broken?"
App returns 500 errors. Ping the server. If ping succeeds with normal latency, the host is up and routable — your app is the problem. If ping fails, the host is unreachable from this part of the internet — escalate to ops, check the cloud provider's status page.
Latency baseline before a deploy
Before moving an origin from one region to another, ping the current and target. Compare RTTs from a few geographically dispersed probers. If the new origin is 80ms further from your user base, expect a noticeable real-world latency increase even if everything else is identical.
Verify route convergence after a network change
ISP changed BGP routing overnight. Ping a host known to be on the affected path. Steady low latency = converged. Sporadic timeouts and high jitter = routing is still flapping; wait or escalate.
Customer complaint triage
Customer says "the site is slow." Ping from our prober — sub-100ms = the issue isn't network latency at the IP level, it's higher up (TLS handshake, application response, DNS). High latency or loss = real network issue, you can hand off to network ops with evidence.
Spot intermittent connectivity
20-packet ping reveals patterns a 5-packet ping hides. 19/20 success at 30ms with one timed-out packet = single dropped packet (normal). 12/20 with random timeouts and RTT all over the map = something on the path is unhealthy (congested link, route flapping).
Reading the result
RTT min / max / avg
Round-trip time in milliseconds. Min = fastest single packet (closest to the true network path latency). Avg = mean across all received packets. Max = slowest, useful for spotting tail latency. A min of 20ms and max of 800ms means the path is mostly fast but has occasional slow packets — congestion or buffer queueing somewhere.
Jitter
Standard deviation of RTT. Low jitter (a few ms) = stable path, packets all take the same time. High jitter (>30ms on a path with avg <100ms) = real-time-sensitive apps (VoIP, video calls) will sound choppy. Routes through congested ISP links or saturated wifi often show high jitter.
Packet loss
Percentage of pings that got no reply. 0% on a healthy path. 1-5% is sometimes acceptable on poor wireless links. >10% means the path is broken — TCP will retransmit constantly, the user sees latency spikes and timeouts. 100% means either total unreachability or the target is configured to drop ICMP.
Why a host might reply slowly even when "up"
ICMP is often deprioritised at routers — they handle real traffic first, ping responses second. So ping RTT can be higher than the actual TCP/UDP path latency. Don't use ping alone for SLA reporting; use ping for binary up/down, use TCP-level checks for latency that matches user experience.
Common pitfalls
"Host says it's up but ping shows 100% loss"
Many firewalls and cloud providers drop ICMP by default. AWS EC2 doesn't allow ICMP inbound unless your security group explicitly permits it. Same for Cloudflare proxied origins (their edge serves HTTP, blocks ICMP to origin). Ping failure ≠ host down — verify with a TCP port check on a known-listening port (80, 443, 22).
Ping works from your laptop but fails from the tool
Different paths. Your laptop sees the path from your ISP; we see it from our prober's ISP. Different paths can have different ACLs, different congestion, different routing decisions. Run the tool with multiple regions if available to see whether it's a single bad path or genuinely broken.
Latency way higher than expected
Could be (1) wrong region — geographically distant prober, (2) route is going through unexpected hops — use traceroute to see, (3) target is queueing ICMP responses behind real traffic. Compare against a TCP connect() time to the same host on a real port — that's usually closer to actual application latency.
Inconsistent results between runs
Internet paths flap. A 5-packet ping is too small a sample for an unstable path. Use 20 packets if you need to characterize stability. Or just accept that ping is a snapshot, not a measurement — for production latency tracking, use continuous monitoring.
Run Ping on every change, not just once.
Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card.
Start freeFrequently asked questions
Why does my host respond to ping in the browser but not in this tool?
Is ping a reliable measurement of network speed?
What's a good ping latency?
Can I ping a website?
Why does the ping show some packets out of order?
Can I ping IPv6 addresses?
My ping says 100% loss but the website works fine — should I be worried?
What's jitter and why does it matter?
Related network tools
- TracerouteTrace the network path hop by hop with per-hop latency (MTR-style).
- Port CheckerTest TCP port reachability and optionally grab the server banner.
- Blacklist CheckTest an IP or domain against 15+ DNS-based blocklists (RBLs).
- What Is My IPSee your public IPv4 / IPv6 address, approximate location (city, region, country), timezone and map coordinates — detected instantly from your connection, no signup.