--- title: Is it the server or my connection? How to ping a server online with Ping description: Video calls stutter, SSH lags and a site feels slow, and nobody knows whether to blame the server or the office line. Pinging the server from outside your network gives you a second opinion: if a data-centre location sees a steady round trip and you don't, the problem is on your side. Here's how to run an online ping test, how to read RTT, jitter and loss, and the ping commands that finish the diagnosis. canonical: https://watchfor.io/blog/how-to-ping-a-server-online --- # Is it the server or my connection? How to ping a server online with Ping 2026-10-04 · WatchFor Team · Guides · guides, networking, performance Video calls stutter, SSH lags and a site feels slow, and nobody knows whether to blame the server or the office line. Pinging the server from outside your network gives you a second opinion: if a data-centre location sees a steady round trip and you don't, the problem is on your side. Here's how to run an online ping test, how to read RTT, jitter and loss, and the ping commands that finish the diagnosis. To tell whether lag comes from the server or from your own connection, ping the server from somewhere outside your network and compare the result with a ping from your machine. If the outside ping shows a steady round trip with no loss and yours jumps around, the problem sits between you and the internet: your Wi-Fi, your router or your ISP. If both look bad, it's the server or the network in front of it. The free [Ping](/ping-test) tool sends ICMP echo requests from a WatchFor location and reports the round-trip time of every packet, the jitter and the packet loss. No signup. ## What this tool answers *Does this host answer, how fast, and how steadily, seen from a data centre instead of from my desk?* Reach for it when a server seems down to you but not to colleagues, when an SSH session or game server lags, after a hosting move to see the new latency, or to check that a firewall change didn't make a host stop answering ping. ## A real example ### Pinging a server online to see whether the lag is on your side Our own complaint, on a quiet evening: pushes to GitHub felt sluggish and a terminal session over the same line stuttered. A local `ping github.com` (20 packets) gave: ```text 20 packets transmitted, 20 received, 0% packet loss, time 9516ms rtt min/avg/max/mdev = 22.181/31.041/65.965/13.996 ms ``` No loss, but the replies swung between 22 and 66 ms, and five of the twenty were above 40 ms. Is GitHub slow, or our line? At the same moment we ran [Ping](/ping-test) against `github.com` with the default 5 pings. Logged out, it runs from the WatchFor location nearest the visitor; for us that's Vilnius, so its path to GitHub's Frankfurt servers is comparable: ![The Ping tool result for github.com: 24 ms average round-trip time, REACHABLE, 0% loss; min 24 ms, avg 24 ms, max 24 ms, jitter 0 ms; sent 5, received 5; five green per-packet bars all labelled 24 ms](/blog/how-to-ping-a-server-online-result.webp) All five replies came back between 23.99 and 24.13 ms. The jitter was 0.05 ms, which the card rounds to 0 ms. From a data centre, GitHub answered like a metronome. One more ping narrowed it down. Our router, `192.168.1.1`, answered 20 of 20 in 0.19–0.31 ms, so the local network was clean. The spikes were therefore between our router and the internet: the ISP access line. A second local run a few minutes later was much calmer (max 34.9 ms), which fits a busy upstream link, not a broken server. **The answer:** GitHub was fine, and so was our LAN. The intermittent jitter was on the ISP side. If it keeps happening, that's the evidence to send the ISP: steady from outside, steady to the router, spiky in between. ## How to read the results | What you see | What it means | | --- | --- | | **Avg RTT (hero)** | Average round-trip time of the replies. Green under 50 ms, amber under 200 ms, red from 200 ms. It depends on distance: a host on another continent can't be green. | | **REACHABLE / UNREACHABLE** | Whether any echo reply came back. Unreachable can mean the host is down *or* that it drops ping; many do. | | **% loss** | Share of packets with no reply in time. Green under 1 %, amber under 5 %, red from 5 %. With 5 packets, one loss is already 20 %, so treat small samples carefully. | | **Min / Avg / Max** | The fastest, mean and slowest reply. Min is the closest to the real network distance; a max far above it means queueing somewhere. | | **Jitter** | How much consecutive replies vary. Under 5 ms is green. Voice and video suffer from jitter more than from steady latency. | | **Sent / received** | Packets out and replies in. | | **Per-packet RTT** | One bar per packet, with its time underneath. Red with ✕ is a lost packet. One tall bar is a blip; a staircase means congestion building up. | ## More ways to use it - **After moving hosts or regions.** Ping the old and the new address to see the latency change your users will get. - **Before blaming the server.** If a user reports a site down, a reachable result from a data centre points at their network, their DNS or their ISP. - **Checking a firewall rule.** Allowed ICMP in a security group? The host should flip from unreachable to reachable. Blocked it on purpose? It should stop answering. - **Behind a CDN.** Pinging a CDN-fronted name measures the nearest edge, not your origin. Ping the origin address to see your server. - **Next step when it's slow.** A [traceroute](/traceroute-online) shows which hop adds the delay; the [traceroute guide](/blog/how-to-run-a-traceroute-online) explains how to read it. ## Tips and gotchas - **No reply doesn't mean down.** Plenty of servers and firewalls drop ICMP: AWS security groups don't allow inbound ping unless you add a rule, and Windows Firewall blocks echo requests by default. Check the service itself with the [port checker](/port-checker) before concluding anything. - **Ping measures the network, not the app.** A 20 ms ping and a 3-second page load can both be true; the delay is then in the server or the application. Ping can't see HTTP. - **Routers deprioritise ICMP.** A busy router may answer ping slowly while forwarding real traffic quickly. One slow packet in a run proves little; a pattern does. - **The free test is a short sample from one place.** Logged out it runs from the location nearest you, over IPv4. For a real loss percentage, run more packets locally or keep a monitor on it. - **Compare like with like.** A ping from Vilnius to Frankfurt and one from Sydney to Frankfurt will never match. Compare a location with itself over time, or with a nearby vantage point, as we did above. - **Name vs address.** A name can resolve to a different address for the tool than for you (GeoDNS, CDNs). If results disagree wildly, ping the same IP from both places. ## Check it from the command line too The two pings that finished our diagnosis, run right after the example: ```bash ping -c 20 -i 0.5 -q 192.168.1.1 ping -c 20 -i 0.5 -q github.com ``` ```text 20 packets transmitted, 20 received, 0% packet loss, time 9576ms rtt min/avg/max/mdev = 0.185/0.223/0.306/0.032 ms --- github.com ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 9517ms rtt min/avg/max/mdev = 22.151/23.703/34.898/2.985 ms ``` `-c` sets the number of packets, `-i` the interval in seconds, `-q` prints only the summary. `mdev` is the standard deviation of the round trips, the command-line cousin of jitter: 0.03 ms to the router, 3 ms to GitHub on this calmer run, 14 ms in the run in the example. On Windows, `ping -n 20 github.com` does the same, and `pathping github.com` adds per-hop loss. To see which hop the spikes start at, `mtr -rwc 20 github.com` sends 20 probes per hop and prints a loss and latency table for every router on the way. ## Keep watching it One ping test tells you about one moment; intermittent loss or jitter like ours only shows up over time. A [ping monitor](/ping-monitoring) pings your host on a schedule from the locations you choose and records RTT, jitter and loss for every check. The **Packet Loss** and **Ping Latency** rules alert when loss or average RTT crosses a threshold you set, and a failure is re-checked from your other locations before an incident opens. Raise **Ping Count** above the default of 1 so the loss percentage means something. ## FAQ **What is a good ping?** Under 50 ms feels instant for most things, 50–100 ms is fine for browsing and calls, and above 150–200 ms becomes noticeable in games and voice. Distance sets a floor: light in fibre needs about 1 ms per 100 km for the round trip. [What is latency?](/blog/what-is-latency) covers the rest. **Why does ping show request timed out when the website works?** The server or a firewall in front of it drops ICMP echo requests. The web server still answers on port 443, which ping never touches. Check that port instead. **What causes packet loss?** Congested links, faulty cables or Wi-Fi interference, overloaded routers and rate limits on ICMP. Loss at the destination matters; loss at one hop in the middle often doesn't. [What is packet loss?](/blog/what-is-packet-loss) explains how to tell them apart. --- Canonical page: https://watchfor.io/blog/how-to-ping-a-server-online · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt