Ping Test — Check Server Response Time

Check whether any website, server or IP address is online and measure response time, latency and packet loss in real time. Free, no account needed.

Enter any domain name, hostname, IPv4 or IPv6 address — tests run from our servers for an accurate external view.

Quick test a popular host

google.com cloudflare.com 8.8.8.8 1.1.1.1 github.com amazon.com

Results for amazon.com ICMP probe

Unreachable

Avg Latency

—

no response

Min Latency

—

no response

Max Latency

—

no response

Packet Loss

100

percent

100%

Round-Trip Time per Packet

4 packets sent · 0 received

Lost

Full Ping Details

Show

Target

amazon.com

Resolved IP

98.82.161.185

Probe Method

ICMP (ICMP Echo Request)

Status

Unreachable

Packets Sent

Packets Recv

N/A

Packet Loss

100%

Min RTT

N/A

Avg RTT

N/A

Max RTT

N/A

Jitter (est.)

N/A

Latency Rating

N/A

IP Details Port Check DNS Lookup New Test

Results not stored

Real-time probe

No sign-up needed

Unlimited free tests

What This Tool Does

This ping test sends ICMP Echo Request packets from our server to your target host and measures the round-trip time for each one to return. We send four packets and report the minimum, average and maximum round-trip times in milliseconds, along with the packet loss percentage. When ICMP is blocked by the target's firewall, the tool automatically falls back to a TCP connection probe on ports 80 and 443, labelled clearly so you always know which method was used.

Round-trip time (RTT)

How long each packet takes to travel to the server and back, measured in milliseconds.

Packet loss

The percentage of sent packets that received no reply within the timeout window.

Per-packet bar chart

Each packet is shown individually so you can spot loss or spikes at a specific position in the sequence.

TCP fallback

When ICMP is blocked, the tool probes ports 80 and 443 instead and labels the result as a TCP probe.

Understanding Latency & Packet Loss

Latency is the time it takes for a packet to travel from our server to the target and back. Lower is better. The thresholds below reflect typical expectations across different use cases:

Latency	Rating	Typical experience
< 20ms	Excellent	Imperceptible delay — ideal for gaming, VoIP and real-time applications.
20–60ms	Good	Smooth for almost all interactive applications.
60–150ms	Fair	Noticeable in competitive gaming; fine for browsing and streaming.
> 150ms	Poor	Sluggish for interactive use — worth investigating routing or server distance.

Packet loss is equally important. Even 1–2% loss degrades voice and video call quality noticeably. At 5% loss, audio becomes choppy. At 100% loss the host is unreachable via ICMP — though it may still be serving web traffic if ICMP is simply blocked. Use the Port Checker to confirm specific services are running, or the HTTP Headers tool to verify web responses are being returned.

Tips for Interpreting Results

TCP probe result — if the method shows TCP instead of ICMP, the server's firewall is blocking ICMP. The TCP time is slightly higher than a pure ICMP time because it includes connection handshake overhead, but still gives a real-world measure of service responsiveness.
High jitter — jitter is estimated as the difference between max and min RTT. High jitter causes choppy voice calls and lag spikes in games, even if average latency looks acceptable. It typically indicates network congestion or routing instability.
Geographic distance matters — ping from our server reflects external reachability, not your personal latency. A server in Australia will naturally show higher RTT from a European probe than a local CDN edge node would.
Use ping alongside DNS and port checks — a passing ping only confirms network-layer reachability. Use DNS Lookup to verify name resolution and Port Checker to confirm a specific service is actually running.
Verify domain registration is current — if a domain suddenly stops resolving, check WHOIS Lookup to confirm it has not lapsed or been transferred.

Frequently Asked Questions

What is a ping test and how does it work?

A ping test uses ICMP (Internet Control Message Protocol) Echo Request and Echo Reply messages, defined in RFC 792, to measure the round-trip time between our server and your target host. We send four small packets and record how long each takes to return, showing minimum, average and maximum round-trip times plus the packet loss percentage.

When ICMP is blocked at the target's firewall, the tool automatically falls back to a TCP connection probe on ports 80 and 443, clearly labelling the result so you always know which method was used. The per-packet bar chart lets you see individual response times so you can spot dropped packets or latency spikes at specific positions in the sequence.

What is a good ping response time?

Under 20ms is excellent — typical for nearby servers or well-optimised CDN networks like Cloudflare or Google. Between 20ms and 60ms is good and suitable for almost all applications. Between 60ms and 150ms is fair — noticeable in competitive gaming but acceptable for browsing and streaming. Above 150ms is considered poor for interactive use and warrants investigation into routing, VPN overhead, or server distance.

For voice and video calls specifically, latency above 150ms starts to create noticeable conversational awkwardness. For real-time multiplayer gaming, players typically notice latency above 50ms. For web browsing and streaming, latency matters far less than bandwidth — most users find anything under 200ms perfectly acceptable for non-interactive use.

What is packet loss and why does it matter?

Packet loss occurs when one or more sent packets receive no reply within the timeout window. Even 1–2% packet loss degrades voice and video call quality noticeably — you'll hear audio dropouts or see video freezing. At 5% loss, audio becomes choppy and gaming experiences visible lag spikes. At 100% loss the host is completely unreachable via ICMP — though the server may still be serving HTTP traffic normally if ICMP is simply blocked at the firewall level.

If you see packet loss in the ping results but the website loads fine in your browser, use our Port Checker to confirm ports 80 and 443 are open. Loss on ICMP alone without loss on TCP ports almost always means ICMP is being selectively dropped by a firewall, not that there is a real connectivity problem.

What does it mean when the tool uses a TCP probe instead of ICMP?

Many cloud servers, load balancers and CDN-proxied domains block ICMP Echo requests at the firewall while allowing web traffic through on ports 80 and 443. When ICMP packets receive no response, this tool automatically switches to a TCP connection test on those ports and clearly labels the result as a TCP probe.

TCP probe times are slightly higher than pure ICMP times because they include connection handshake overhead — the SYN, SYN-ACK, ACK sequence adds a small fixed cost. However, TCP times represent real-world service responsiveness rather than raw network latency, which is often more useful for diagnosing whether users are experiencing slow page loads.

Why does the ping run from your servers, not my browser?

Browsers do not have access to raw ICMP sockets for security reasons — ICMP requires privileged socket access at the operating system level that web pages are not permitted to use. Running the probe from our server provides a stable external baseline unaffected by your local ISP conditions, Wi-Fi interference, VPN tunneling, or browser extensions.

This external perspective is exactly what matters for diagnosing whether a server is publicly reachable — it tells you what search engine crawlers, uptime monitors, and your users from the broader internet actually experience. Pair it with a local ping from your terminal to compare external versus personal latency and isolate whether a problem is on your end or the server's end.

Why might a ping test time out even when a website loads fine in my browser?

This is expected and very common behaviour. Many production servers — especially those behind a CDN, load balancer or cloud firewall — intentionally drop ICMP Echo requests as a basic security measure, while continuing to accept web traffic on ports 80 and 443 without issue. Cloudflare, AWS, and most major cloud providers block ICMP by default on many configurations.

If ICMP is fully blocked, this tool automatically falls back to a TCP connection probe so you still get an accurate reachability and latency result, clearly labelled as a TCP probe. A 100% packet loss result on ICMP with a working website in your browser is almost always ICMP being blocked, not a real connectivity problem.

When should I use ping versus a port check?

A ping test confirms a host's IP address is reachable at the network layer — it verifies the server is online and responding to network probes. A port check goes one layer deeper and verifies a specific application is running and actively accepting TCP connections on a particular port.

A server can pass a ping test while having a crashed web server with port 443 refusing connections. Use ping first for basic reachability, then port checking for service verification, then our HTTP Headers tool to confirm the application is returning correct responses. Together these three checks cover the network, transport and application layers of the stack.

Is this ping test completely free to use?

Yes — unlimited tests, no account required, no data stored. The quick-test buttons above let you instantly benchmark well-known public hosts like Google, Cloudflare and GitHub to get a baseline reading before testing your own server. Comparing your server's RTT against a known-good public host like 1.1.1.1 is useful for understanding whether high latency is caused by geographic distance, server load, or your own network path.

For a complete server health workflow, combine the ping test with our DNS Lookup to verify name resolution, Port Checker to confirm services are running, SSL Checker to verify the certificate is valid, and HTTP Headers to check security headers — all free and real-time with no sign-up.