How to Prove Packet Loss to Your ISP (and Get It Fixed)
You call your ISP, explain that your games lag and your calls stutter, and hear the classic answer: “Everything looks fine on our end.” They’re not necessarily lying — they’re looking at the wrong data. The fix is to bring evidence they can’t wave away.
Quick translation of the two terms that carry this guide: packet loss means some of the data your PC sends never arrives — in game terms, bullets that never left the barrel. And UDP is how games send that data: tiny messages fired at the server with no delivery receipt and no resend, so a lost one is simply gone. Your ISP’s standard line check doesn’t look for either, which is exactly why the proof has to come from you.
Why “it looks fine on our end” is usually true
First-line support can see your modem’s signal levels and whether the line is synced at the right speed. What they generally cannot see is what happens to your traffic minute to minute: the 2% packet loss that only appears at 8 pm, the 600 ms spike every time the neighborhood comes home, the 40-second dropouts twice an evening. These faults are real, common, and almost invisible to a once-a-day line check. So the burden of proof lands on you.
Step 1: Eliminate your own network first
Before blaming the ISP, make sure the problem survives past your own equipment — otherwise the first question they ask (“are you on Wi-Fi?”) ends the call.
- Test on Ethernet. Wi-Fi adds its own jitter, retransmissions and spikes that have nothing to do with your ISP. See Wi-Fi vs Ethernet for gaming and re-test wired.
- Rule out bufferbloat. If lag only appears while the connection is busy, the queue is in your router, and your ISP can’t fix it — but a router setting can. Run the bufferbloat stress test.
- Reboot and re-seat the modem/router once, and bypass the router entirely if you can, so the signal path is as simple as possible.
If the problem persists on a wired connection with an idle line, you have something worth reporting.
Step 2: Collect timestamped evidence
The single most persuasive thing you can bring is a continuous, timestamped log. “It lags sometimes” is an opinion. “Here are 14 packet-loss events between 19:00 and 23:00 yesterday, each with a start time and duration” is a fault report.
What good evidence looks like:
- Continuous monitoring over hours and days, not a single speed test — intermittent faults hide from one-shot tests (here’s why averages hide them).
- Exact timestamps and durations for every lagspike, loss burst and outage.
- True packet loss measured over UDP, since TCP tests retransmit and hide loss. LagScope’s GAME TRAFFIC mode sends 128-byte UDP packets at 30 Hz — the same shape as real game traffic — so the loss you record is the loss your game felt.
- Repetition. One bad evening is an anecdote; the same loss window three nights running is a pattern a network engineer can chase.
LagScope generates a one-click ISP evidence report from your session — a clinical, timestamped summary of every event, your baseline latency, jitter and loss — plus a CSV export and a shareable proof link that renders a read-only snapshot of the session. All of it is generated locally in your browser; only the proof snapshot you choose to share leaves your machine.
Step 3: Add path context with traceroute
A traceroute (or better, mtr / WinMTR, which traces continuously) shows where packets slow down or vanish. If loss starts at the first hop, it’s your equipment. If it starts several hops in, inside your ISP’s network or their upstream, that’s theirs. Run it during a bad window and save the output — support can escalate far faster when you can say “loss begins at hop 4, which reverse-resolves to your regional router.”
Step 4: Make the call (what to actually say)
- State it as a measured fault, not a feeling: “I’m seeing 2–5% UDP packet loss and latency spikes above 500 ms, on a wired connection, every evening between 7 and 10 pm.”
- Say you’ve eliminated your side: tested on Ethernet, with an idle line, router bypassed if possible.
- Offer the evidence: “I have a timestamped log and a link to a session snapshot — where can I send it?”
- Ask for what you want: a line check for errors on the node/segment, a technician visit, or escalation to second-line network support — not another modem reboot script.
- Take the ticket number, and keep monitoring. If they fix it, your log will show it; if they don’t, your next call starts from stronger evidence.
If they still won’t act
Escalate calmly and in writing: a formal complaint through the ISP’s own channel, then the regulator or consumer-protection body in your country if it goes nowhere — regulators take documented, repeated faults seriously. In many regions you can also exit a contract penalty-free when the service demonstrably doesn’t match what was sold. Your continuous log is the backbone of every one of those paths.