Ping & Packet Loss: Is the Network Path Dropping Traffic?
Using ping and tracert to measure latency and packet loss, and to localize where loss is happening.
Tools required: ping, tracert
Overview
Packet loss and high latency cause symptoms that look like everything else - slow pages, dropped calls, timeouts. Ping is the simplest, fastest way to confirm whether the network path itself is the problem.
Step-by-Step Manual Check
Run a sustained ping to get a real statistical sample
A single ping tells you almost nothing - loss and latency spikes are often intermittent, so you need a sample large enough to catch them.
ping -n 100 example.comOn macOS/Linux, use: ping -c 100 example.com
Healthy result
Ping statistics for x.x.x.x:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss)
Approximate round trip times:
Minimum = 12ms, Maximum = 18ms, Average = 14msProblem result
Packets: Sent = 100, Received = 82, Lost = 18 (18% loss) Minimum = 12ms, Maximum = 890ms, Average = 145ms
What it means
Any sustained loss above roughly 1-2% is worth investigating - real-time applications like calls/video degrade noticeably above that. A high maximum time with a normal average (occasional spikes) suggests intermittent congestion rather than a constantly bad link.
If unresolved, escalate to: Level 1 — Basic
Run a continuous ping while reproducing the issue
If the problem is intermittent (e.g. "the call drops every few minutes"), a continuous ping running in the background while the issue happens again is the most direct way to correlate the two.
ping -t example.com-t pings indefinitely until stopped with Ctrl+C. On macOS/Linux, ping without -c already runs continuously.
Healthy result
Steady replies with consistent time= values throughout, even while reproducing the reported issue.
Problem result
"Request timed out." lines appear, clustering at the same moments the reported issue occurs.
What it means
If timeouts line up exactly with when the user says the problem happens, this confirms it's a network-path issue and not an application bug - hand this timestamped evidence to whoever owns the next escalation.
If unresolved, escalate to: Level 2 — Intermediate
Trace the path to find where loss is introduced
Ping only tells you loss exists end-to-end; tracert shows every router hop along the way, which localizes the loss to a specific segment of the path.
tracert example.comOn macOS/Linux, use: traceroute example.com
Healthy result
A list of hops with consistently low, gradually increasing response times, ending at the destination.
Problem result
A specific hop shows "Request timed out" or a large time jump (e.g. hop 4 is 15ms, hop 5 is 400ms), and every hop after that stays elevated.
What it means
The first hop where response time permanently jumps (and stays elevated for all following hops) is approximately where the problem is introduced. If that hop is inside your own ISP's network, this is evidence to escalate to the ISP rather than keep investigating locally. Note: some routers deprioritize or block the ICMP traffic tracert uses, causing a single hop to show timeouts while the path is actually fine beyond it - a one-off timeout at a single hop with normal times before and after is usually not a real problem.
If unresolved, escalate to: Level 3 — Expert / Critical
Interpreting the Results
Loss and latency at hop 1 (your own router) points to local Wi-Fi/cabling; loss appearing a few hops in but before it leaves your ISP's network points to the ISP; loss appearing only in the last few hops near the destination points to the destination's own network or hosting provider.
Common Causes
| Symptom | Likely Cause | Fix |
|---|---|---|
| Loss/high latency only over Wi-Fi, not on a wired connection | Wi-Fi interference or a weak signal, not a wider network issue | Move closer to the access point, switch to 5GHz/6GHz band, or use a wired connection to confirm. |
| Loss appears at a hop still inside the local ISP's network | ISP-side congestion or a faulty router on their end | This needs to be escalated to the ISP with the tracert output as evidence. |
| Loss only during specific times of day | Network congestion during peak usage hours | Confirm the pattern with repeated tests at different times before escalating. |
Automated by
Diagnostic Suite - Ping Drop Test (Option 3)
Runs an extended ping test automatically and produces a packet-loss report over time - useful for catching intermittent issues that a manual one-off test would miss.