What to Send Your ISP or IT Support When Your Internet Breaks

Every support conversation about a broken connection opens the same way: what browser, what version, what operating system, are you on Wi-Fi, who is your provider. Most people cannot answer, and a fair number answer wrongly. This is what each question is actually for, and how to collect all of it in one pass with the connection report.

Quick answer

Support needs six things before it can do anything useful:

Everything on that list is readable from a browser in a few seconds. None of it requires installing anything.

Why collecting them together matters

The usual advice is to run a speed test and paste the number. That is the least useful thing you can send, because bandwidth is rarely the problem.

More importantly, values gathered piecemeal describe different moments. If you check your latency, then five minutes later check your connection type, then ten minutes after that run a speed test, you have three snapshots of a link that may have changed between each one. An agent reading them assumes they describe the same state. On a connection that fluctuates — which is exactly the sort of connection people contact support about — that assumption is wrong and it sends them down the wrong path.

Collect everything in one pass, at one timestamp. That is the whole reason the connection report exists.

What each field is really for

Public IP address and ISP

Your IP identifies your line to your provider and tells third-party support who to escalate to. The organisation name and ASN attached to it are frequently more useful than the address itself — "AS17557, Pakistan Telecommunication" tells an agent more than four numbers do.

One detail people miss: if your address falls in the 100.64.0.0/10 range, you are behind carrier-grade NAT and share a public address with other customers. That single fact explains an entire category of "port forwarding does not work" and "the game cannot host" tickets, and it is worth stating up front.

Browser and version, not just browser

"Chrome" is not an answer. Faults are version-specific far more often than browser-specific, and the rendering engine matters independently — every browser on iOS uses WebKit regardless of its name, which surprises people filing bugs against "Chrome on iPhone".

Two adjacent values are worth more than they look. Whether cookies are enabled is obvious; whether local storage can actually be written is not, and it is a common cause of "the site keeps logging me out". Storage being blocked looks identical to storage being empty unless something tries to write to it:

function storageAvailable() {
  try {
    localStorage.setItem('__test', '1');
    localStorage.removeItem('__test');
    return true;
  } catch {
    return false;   // private mode, blocked cookies, or a strict policy
  }
}

Latency, and the number most people never send

A single ping tells you very little. Two numbers tell you almost everything:

• Idle latency — round-trip time on a quiet connection
• Latency under load — the same measurement while the link is saturated

A connection with 20 ms idle and 300 ms loaded latency will feel broken during video calls while a speed test happily reports the full advertised bandwidth. That gap is bufferbloat, and it is the single most common explanation for "my internet is fast but calls are terrible". Our speed test measures both; the latency test covers idle in more detail.

Send the median of several samples, not one reading. One slow request should not define your connection.

VPN or proxy

If a VPN is active, everything downstream changes: your apparent location, your route, your latency, and which server you reach. It is the most common cause of a fault that only you can see, and the first thing worth ruling out. The VPN leak test covers this in depth.

Device details

Screen size, pixel ratio and GPU matter more than they sound for anything visual. A layout bug that only appears at one pixel ratio is close to impossible to reproduce without knowing the ratio. Note that physical resolution and viewport size are different numbers and support usually wants both.

What a browser genuinely cannot tell you

Be aware of the boundary, so you do not waste an hour looking for something no website can provide:

• Your router's settings or its WAN address. Read it from the router's own status page.
• Your local IP or the other devices on your network.
• Which DNS server your system actually uses. A page can query DNS-over-HTTPS resolvers, but it cannot see your operating system's resolver.
• Anything outside plain HTTPS — torrent traffic, game ports, VoIP.

If an agent asks for any of these, they need you to look at the router or run a desktop tool. No web page can do it, and one claiming otherwise is guessing.

A note on what you are sharing

A connection report contains your IP address and a rough location. That is fine to send to your own ISP, who already has both. For third-party support it is worth masking the last half of the address — the first half still identifies your network and provider, which is what an agent needs, and support tickets have a habit of ending up in shared inboxes.

Read the text before you send it. That advice sounds obvious and is ignored constantly.

Collect it in one pass

The connection report runs every check above at once, shows you the result, and gives you one plain-text block to paste into a ticket — with your IP masked by default. Everything is measured in your browser and nothing is uploaded.

If you only need one answer rather than all of them, the individual tools are quicker: your IP, your ISP, browser details, and ping and latency.