IA Internet Analysis
Log in
SUPPORT EVIDENCE

How to Collect Evidence of ISP Lag Before Contacting Support

Document wired and wireless observations, timing, destinations and failed attempts without presenting one test as proof of ISP fault.

Run a controlled baselineUse the experiment worksheet
SHORT ANSWER

One speed test cannot prove that your ISP caused lag. Build a repeatable record on one wired device, at several times and to more than one destination. Preserve the method and failed attempts so support can distinguish local, access-network and destination problems.

STEP BY STEP

How to run the check

  1. Write down the complaintRecord symptoms, approximate times and affected applications. Keep your account number, IP and full address out of publicly shared material.
  2. Compare wired and wirelessUse the same device and test method. If only Wi-Fi fails, investigate that segment first. A wired result still includes the device, router and endpoint.Open the relevant tool →
  3. Repeat across time and destinationsCollect quiet and busy-hour observations on several days. Keep endpoints named and failures included. A single remote service may itself be impaired.
  4. Send a bounded reportUse Share result to copy an ISP report or download printable HTML. Review metrics and privacy notes, add private service details only in your provider’s support channel, and ask for the next diagnostic step.
INTERPRETATION

What the signals mean

Wi-Fi-only issueLocal-link evidence

A healthy wired comparison reduces suspicion of the access line but is not conclusive for every application.

Multiple wired destinationsBroader pattern

Repeated impairment on several destinations is stronger evidence than a single site failure.

Busy hoursRepeatable schedule

Home traffic and upstream congestion can both follow a schedule; record whether local traffic was paused.

COMMON QUESTIONS

Frequently asked questions

Can traceroute identify the responsible ISP?

It can show responding hops, but replies may be rate-limited and paths may be asymmetric. A slow intermediate response alone does not prove forwarding delay.

What should a support report include?

The symptom, timestamp, method, device/access mode, endpoint, repeated results and failure counts. State what is still unknown instead of accusing a specific segment.