How to Prove Packet Loss to Your ISP

Support will tell you to reboot the router. Here is the evidence that ends that conversation — what to measure, how to capture it on Windows, macOS or Linux, and how to present it so the ticket gets escalated.

You know something is wrong. Calls break up, games rubber-band, video freezes for two seconds and recovers. You call your ISP, and within ninety seconds you are being asked to reboot the router you already rebooted twice.

This is not because support staff are unhelpful. It is because "my internet is bad" is not actionable, and the one number they can check — your line speed — almost always looks fine. Packet loss does not show up in a speed test. You have to measure it separately and hand over something they cannot dismiss.

Here is what that evidence looks like.

The short version

1. Test over Ethernet, not Wi-Fi — Wi-Fi loss is your problem, not your ISP's.
2. Measure loss over several minutes, not seconds. Brief tests miss intermittent faults.
3. Record upload and download separately. Direction tells the ISP where to look.
4. Run an MTR to find the first hop where loss begins and continues.
5. Check the return path, which ordinary traceroutes never measure.
6. Repeat at different times of day, for at least three days, and keep timestamps.
7. Send a link, not a screenshot, and ask explicitly for escalation.

Each of those is expanded below. If you only do one thing, do step 4 — naming a specific hop is what moves a ticket out of tier-1 support.

Why your speed test says everything is fine

A speed test measures throughput: how much data your connection moves in a few seconds. It says nothing about whether individual packets arrive intact or on time.

The reason it hides packet loss is reliable transport. Most speed tests run over HTTP on TCP, and TCP notices missing packets and retransmits them automatically. The data still arrives; the transfer just takes marginally longer. A connection losing 2% of packets can still report near-line-rate throughput because retransmission absorbs the damage before it reaches the number on your screen.

This is worth stating precisely, because "TCP hides loss" is a slight oversimplification. The property that hides loss is reliability, not TCP specifically. A speed test running over HTTP/3 uses QUIC, which is built on UDP — and it masks packet loss just the same, because QUIC retransmits too. What matters is whether the protocol resends lost data, not which transport it sits on.

Real-time media is the opposite case. A video call or a game sends audio and video over an unreliable channel on purpose, because a frame that arrives 300 ms late is worthless — playing it would put the conversation out of sync. There is nothing to retransmit into, so a lost packet is simply gone, and you hear it.

So "the speed test is fine" and "my connection is broken" are not contradictory statements. They measure different things.

How much packet loss actually matters

Two caveats before you use those numbers.

Distribution matters as much as the percentage. Loss spread evenly is far more survivable than the same percentage arriving in bursts. Codecs conceal isolated missing packets by interpolating; they cannot conceal 40 consecutive packets vanishing. A connection showing 1% loss in tight bursts can sound worse than one showing 2% spread thinly. If your test reports loss but calls are fine — or the reverse — burstiness is usually why.

Context matters too. Direction, round-trip time and the application all change the impact. Loss on your upload affects what other people hear from you; loss on download affects what you receive.

That said, for a consumer broadband connection, sustained loss above 1% is worth a ticket, and sustained loss above 2.5% is a fault by any reasonable standard — ISP service targets generally sit well under 1%.

Testing packet loss on Windows, macOS and Linux

You do not need any software to get a first measurement. Every operating system ships with ping.

Windows — send 100 packets and read the summary:

ping -n 100 1.1.1.1

macOS and Linux — the same test:

ping -c 100 1.1.1.1

Both print a loss percentage at the end. On Windows the line reads Packets: Sent = 100, Received = 98, Lost = 2 (2% loss); on macOS and Linux it reads 100 packets transmitted, 98 received, 2% packet loss.

Three things to know before you trust that number.

Pick your target carefully. Public addresses commonly rate-limit ICMP, ignoring some pings to protect themselves — so loss measured against any single one of them, 8.8.8.8 and 1.1.1.1 alike, is not proof of end-to-end loss. Better is to test your ISP's own gateway alongside one destination beyond it (see the next section), so you have something to compare against.

ICMP is not your traffic. Ping measures loss for ICMP echo packets, which routers frequently deprioritise relative to real traffic. A clean ping does not prove your video call is clean, and a lossy ping does not always mean your data is being dropped.

100 packets is roughly 100 seconds, which is a small sample. It will catch a hard fault. It will routinely miss the intermittent kind that ruins one call an hour — which is exactly the kind you are usually trying to prove.

So use ping as a first look. For evidence you intend to send someone, you want a longer measurement over an unreliable transport, which is what the full connection test does — it measures loss over UDP, separates upload from download, and reports jitter alongside it.

Isolate your own network first

Before blaming anyone upstream, find out whether the loss starts inside your house. This takes two minutes and pre-empts the first thing support will ask.

Ping your own router, then ping something on the internet:

ping -c 100 192.168.1.1        # your router — check its actual address
ping -c 100 1.1.1.1            # a destination beyond your ISP

That last row catches people out constantly. A router that ignores some of its own pings while forwarding your traffic perfectly is normal behaviour, not a defect.

Then rule out the rest:

1. Test over Ethernet. Wi-Fi packet loss is extremely common and is not your ISP's problem. If you cannot test wired, at least test standing next to the access point, and say so in the ticket.
2. Test with nothing else running. A cloud backup or a large download will saturate the line and produce loss that is entirely your own doing.
3. Bypass your own router. Connect a machine directly to the modem. If loss disappears, your router is the fault.
4. Try a second device. Loss on one machine only points at that machine — a bad cable, a failing NIC, a driver problem.
5. Check the physical layer. On cable connections, signal levels and correctable/uncorrectable codeword counts in the modem's status page are often the actual smoking gun.

If loss persists on a wired connection, on more than one device, with the router bypassed and nothing else running, you have eliminated everything you control. The remaining candidates are the line into your home, your ISP's access network, or a network beyond it — and the next section narrows that down further.

Finding where the loss starts

This is the piece that turns a complaint into an escalation. Run an MTR test — it combines traceroute and ping, probing every router between you and a destination continuously, and reports loss per hop.

What you are looking for is the first hop where loss appears and continues to every hop after it.

Pattern 1 — real loss. This one is constructed, using documentation-range addresses, because a genuinely faulty path is not something we can produce on demand. The shape is what matters:

Hop   Address           Loss%
1     192.168.1.1        0.0%
2     10.20.30.1         0.0%
3     203.0.113.17       6.2%
4     198.51.100.4       6.8%
5     198.51.100.90      6.1%
6     93.184.216.34      6.5%

Loss begins at hop 3 and every subsequent hop inherits it. That is a genuine fault at or just before hop 3, and hop 3's address is what you name in the ticket.

Pattern 2 — not a fault. This one is a real capture, run from our San Jose server to 1.1.1.1 on 25 August 2026:

HOST: network-tests-sanjose-1     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 140.91.234.180             0.0%    50    0.3   0.3   0.2   0.4   0.0
  2.|-- 172.68.188.109             0.0%    50    0.8   0.7   0.4   2.2   0.2
  3.|-- 172.68.188.108            58.0%    50    1.3   3.3   1.0  16.7   4.3
  4.|-- 172.68.188.107             0.0%    50    1.2   2.4   0.9  20.5   3.3
  5.|-- 1.1.1.1                    0.0%    50    0.9   0.9   0.9   1.6   0.1

Hop 3 reports 58% loss and everything after it is perfectly clean. If hop 3 were genuinely dropping well over half its traffic, hops 4 and 5 could not possibly be at zero — their packets pass through hop 3 too. That router is discarding probes addressed to itself while forwarding transit traffic untouched, and the path is healthy end to end.

Here is the same effect in a milder form, from our Ashburn server on the same day — 8% at hop 5, destination clean:

HOST: networks-tests-asbhurn-1    Loss%   Snt   Last   Avg  Best  Wrst StDev
  4.|-- 173.245.63.109             0.0%    50    0.6   0.6   0.5   0.7   0.0
  5.|-- 173.245.63.179             8.0%    50    1.4   2.9   1.3  21.8   4.1
  6.|-- 1.1.1.1                    0.0%    50    0.8   0.8   0.7   0.9   0.0

Asterisks are the same story. A hop that answers nothing at all is usually configured not to reply, not broken. From San Jose to 8.8.8.8, hop 3 is silent while everything past it responds normally:

HOST: network-tests-sanjose-1     Loss%   Snt   Last   Avg  Best  Wrst StDev
  2.|-- 140.204.60.74              0.0%    50    0.8   1.4   0.5  17.2   3.3
  3.|-- ???                       100.0    50    0.0   0.0   0.0   0.0   0.0
  4.|-- 142.251.69.89              0.0%    50    2.0   2.1   1.2   3.2   0.5
  5.|-- 142.251.241.105            0.0%    50    0.9   0.9   0.8   1.1   0.0
  6.|-- 8.8.8.8                    0.0%    50    0.9   0.9   0.8   1.2   0.1

Reporting pattern 2 as a fault is the fastest way to have your ticket closed as "no problem found", and it is the single most common mistake people make with MTR output. If you want the full column-by-column breakdown, see how to read MTR results.

Check the return path

Here is what almost nobody checks, and what frequently explains a fault that "does not exist" according to your ISP.

Routing on the internet is asymmetric. The path your packets take to a server is often not the path the replies take back. A standard traceroute or MTR from your machine only measures the outbound direction. If the fault is on the return path, your own tests will look clean — and so will your ISP's, because they will run the same kind of test.

A reverse trace — MTR run from a remote server back toward your address — provides evidence about that direction which a local MTR cannot observe. Our MTR tool can run in reverse, which is unusual; most online traceroute tools only test outbound.

Be careful how you characterise the result. Loss appearing on a return-path hop is strong evidence that the problem is inbound rather than outbound, and it tells you roughly where to look. It is not by itself proof of which organisation owns the faulty equipment — hop addresses can be misleading, and the responsible party may be one network over. Present it as evidence about direction, which is genuinely useful and hard to argue with, rather than as a verdict.

The full explanation of return-path testing covers how to read one.

Establish the pattern over time

One bad test proves nothing. Support will assume you caught a transient blip, and they will often be right.

What proves a fault is repetition. Run the test at least three times a day for three days, and record every result. You are trying to establish one of two things:

• Consistent loss at all hours — a hard fault, usually physical or a configuration problem.
• Loss that follows a schedule — typically evenings between roughly 7pm and 11pm. That is congestion: your local segment is oversubscribed.

Congestion patterns are particularly worth documenting, because ISPs frequently know about them already, and a customer with timestamped evidence gets moved up the list for a capacity upgrade.

Packet loss, latency and jitter are different problems

Worth knowing which one you actually have, because they have different causes and different fixes.

If your loss numbers are clean but calls still break up, the culprit is usually one of the other two — that case is covered here.

How to write the ticket

Structure matters more than length. Support systems route on keywords and escalate on specifics.

Subject: Sustained packet loss to first-hop and beyond — [your account number] Since [date] I have measured consistent packet loss on a wired connection. This is not a speed issue; throughput tests normally at [X] Mbps. Measurements: [N]% packet loss sustained over UDP, measured [N] times daily since [date]. Full results: [paste your results link] Path analysis: MTR shows loss beginning at hop [N] ([IP address]) and continuing to the destination. Hops 1 through [N-1] are clean. This is past my equipment. Testing conditions: wired Ethernet, router bypassed, no other traffic, reproduced on two devices. Pattern: [consistent at all hours / concentrated between 7pm and 11pm daily]. I would like this escalated to network operations rather than tier-1 troubleshooting.

Three details in that template do most of the work: naming the specific hop, stating that you already bypassed your own equipment, and explicitly requesting escalation. Tier-1 support is scripted; giving them a reason the script does not cover is what moves the ticket.

Attach a link, not a screenshot

Every completed test on NetworkTests produces a permanent result URL. Paste that into the ticket.

This matters more than it sounds. A screenshot is a claim; a link is a record with timestamps, server location and full hop-by-hop data that the ISP's own engineers can open and read. When a ticket reaches network operations, having something they can inspect directly — rather than a JPEG of a number — measurably changes how it gets handled.

If they still say no problem found

Two things left.

Ask which direction they tested. ISPs routinely test only outbound from their equipment toward you. If your evidence shows loss on the return path, say so explicitly and ask them to test in that direction.

Escalate outside support. In most countries, ISPs are subject to a regulator or an ombudsman scheme, and a documented fault with timestamped measurements that has been open for weeks is exactly the kind of case those bodies exist for. Say that you intend to do this, in writing. Tickets tend to move.

The whole point of measuring properly is that it removes the argument about whether a problem exists, and leaves only the question of who fixes it.

Frequently asked questions

How do I test packet loss to my ISP?

Ping your router and a destination beyond it, compare the two, then run a longer measurement over UDP with the connection test and an MTR to find which hop loss begins at. Testing only one destination tells you loss exists but not where.

How much packet loss is normal?

Under 0.1% is excellent and effectively invisible. Up to 1% is tolerable for most uses. Above 1% sustained is worth reporting, and above 2.5% will break calls and games. Occasional single lost packets to a busy router are normal and not a fault.

Can a speed test detect packet loss?

Generally no. Speed tests use reliable transports that retransmit lost packets automatically, so loss is repaired before it reaches the throughput figure. You need a measurement over an unreliable transport, which is what a UDP-based test provides.

How do I check packet loss on Windows?

Run ping -n 100 1.1.1.1 in Command Prompt and read the loss percentage in the summary. Use it as a first indication only — it measures ICMP over about 100 seconds, which will miss intermittent faults.

How do I check packet loss on Mac or Linux?

Run ping -c 100 1.1.1.1 in Terminal. The summary line reports the loss percentage. The same limitations apply as on Windows.

Can Wi-Fi cause packet loss?

Yes, and it is one of the most common causes. Interference, distance, channel congestion and older hardware all produce loss before your traffic ever reaches the router. Always confirm a fault over Ethernet before contacting your ISP.

Does 1% packet loss matter?

For file downloads and streaming, barely — retransmission and buffering hide it. For voice, video calls and gaming, 1% is at the threshold where people start noticing, and it matters considerably more if the loss arrives in bursts rather than spread evenly.

What does packet loss at one MTR hop mean?

If it clears at the next hop, it means that router deprioritises replies to itself and is forwarding your traffic normally — not a fault. If it continues through every subsequent hop, the loss is real and begins at or before that router.

How do I know whether packet loss is my ISP's fault?

Eliminate your own equipment first: test wired, with the router bypassed, on more than one device, with nothing else using the connection. If loss survives all four, it is beyond your control, and an MTR will indicate where it begins.

Why does my ISP say there is no problem?

Usually because they tested throughput rather than loss, or tested only the outbound direction. Ask specifically which direction was tested, and supply your own timestamped measurements showing loss beginning at a named hop.