ISP Blaming User Equipment: Automated Speedtest Evidence

LIMEHAWK - Managed IT

Home>Incident Reports>ISP Blaming User Equipment: Automated Speedtest Evidence

Incident

Manufacturing client reported intermittent "internet slowdowns" that were hammering their ERP system. VoIP calls were dropping mid-sentence. Cloud backups were timing out. The ISP sent a tech who ran one speedtest at 2:14 PM, got a normal result, and declared "your internal network equipment is the problem." Their closing recommendation was to replace a stack of managed switches — about $40K in hardware. The client was ready to cut the check by the time they looped us in.

The blame game

The ISP tech's "evidence" in the ticket:

- speedtest at 2:14 PM: 487 Mbps down / 52 Mbps up
- conclusion: "speeds are fine, not our problem"
- recommendation: "replace your switches"

Classic ISP move — run a single test during off-peak hours, declare victory, close the ticket. But the user complaints were clustered between 8-10 AM and 1-3 PM, which was exactly when production ERP traffic and cloud backups were running hardest. One 2 PM test in the middle of a lull proves nothing. We needed continuous evidence, from multiple endpoints, timestamped, for long enough that "cherrypicked" wasn't a defense.

Solution

Deploy automated Ookla speedtest across 47 endpoints, run it every 2 hours, and sync every result into the RMM with a timestamp and the result URL. Build an irrefutable timeline of actual network performance instead of a single snapshot.

Why ookla cli

The Ookla speedtest CLI is the right tool here for specific reasons:

- same backend: hits speedtest.net servers the ISPs themselves use
- JSON output: structured data we can trend and graph
- result URLs: each test produces a shareable URL with a timestamp
- no browser: runs headless via RMM, no user involvement

When disputing with an ISP, using their preferred measurement tool removes the "your testing tool is inaccurate" defense before they can raise it. Every test generates a unique Ookla result URL they can verify independently on their end.

The evidence

After one week of automated testing — 84 tests per endpoint, 3,948 total — the pattern was obvious:

- 6 AM - 7 AM: 491 Mbps — normal
- 8 AM - 10 AM: 47 Mbps — 90% degradation
- 10 AM - 1 PM: 483 Mbps — normal
- 1 PM - 3 PM: 52 Mbps — 89% degradation
- 3 PM - 11 PM: 489 Mbps — normal

Peak business hours showed consistent 90% speed reduction across ALL 47 endpoints simultaneously. Internal switches do not cause synchronized degradation across an entire site — that's upstream congestion, and it's on the provider's side of the demarc.

Outcome

We presented the ISP with a 168-page PDF of timestamped speedtest results. Their network engineer came back within two days and confirmed an oversubscribed node serving the client's building. The client got bumped to a 1 Gbps circuit (up from 500 Mbps) at the same rate they were already paying, billed as a "service credit." Zero switches were replaced. The automated tests are still running monthly so we catch any backslide early.

data points collected: 3,948 speedtests
ISP response: admitted node congestion
resolution: bandwidth upgrade at same price
switches replaced: zero ($40K saved)

Key takeaways

Takeaway

one speedtest proves nothing — trend data across time-of-day wins ISP disputes.

Takeaway

use the ISP's own preferred tool (Ookla) to close off the "bad test" excuse.

Takeaway

sync results to the RMM for historical records and easy export.

Takeaway

correlate test timestamps with user complaint times — the pattern does the arguing for you.

Need help with something like this? Contact us

• Automating CrushFTP Upgrades and In-Place Updates (Automation)

• PC Replacement: Zero Data Loss User Profile Migration (Automation)

• Winget for RMM: Silent Software Deployment at Scale (Automation)