Connection Check Guide

A reference for the DeskTest.net Connection Check. One click runs five layered checks in your browser and leads with a single plain-language answer to the question everyone actually asks: is it your device, your Wi-Fi, your ISP, or the service? This guide explains what each layer measures, how the verdict is decided, what the browser honestly cannot tell you, and how to hand the report to your provider.

Open the Connection Check ->

What the Connection Check does

Most "the internet is broken" tickets are really one of four different problems: your own device or local network, your Wi-Fi, your ISP's line, or the cloud service you are trying to use. A bandwidth number cannot tell those apart - a link can show 200 Mbps and still drop every video call. The Connection Check runs five quick layers inside this browser tab, watches the connection over time rather than in a single snapshot, and rolls the results into one attribution verdict at the top of the page. It leads with the verdict, not a speed reading.

The five layers

Every run performs the same five layers, in order. Each is graded OK (green), Attention (amber) or Problem (red), and each feeds the single verdict above.

1. Reachability

First it reads whether the browser thinks it is online, then fetches the edge and reports your public IP, whether you are on IPv4 or IPv6, the Cloudflare location that answered, and the round-trip time out to the internet. Reaching the internet is OK; no reply at all is a Problem and short-circuits the run - if nothing can get out, the remaining layers have nothing to measure. This round-trip is browser-to-internet-edge; it is not the hop to your local router (see what the browser cannot tell you).

2. Path-quality soak

This is the layer a normal speedtest never does. It opens a WebSocket to the edge and holds it open for about 24 seconds, sending a numbered ping every second and timing each echo. From that it measures packet loss (pings that never came back), jitter (how much the round-trip varies), latency spikes, and how often the connection dropped and reconnected. A clean soak is OK; a few blips are Attention; repeated loss or reconnects is a Problem. Sustained loss and jitter are what actually break calls, remote desktop, and live dashboards, even when bandwidth looks fine. Keep the tab in the foreground during the soak - a backgrounded tab throttles timers and can fake drops.

3. Bandwidth headroom

It streams throwaway bytes down from the edge (using the browser's streaming reader, capped in both bytes and time) and posts a generated buffer back up, and reports the download and upload speed in Mbps. This is deliberately one input, not the headline: a fast number does not mean a healthy connection, and a stable-but-modest link is usually better for real work than a fast-but-flaky one. Very low bandwidth on an otherwise stable link is flagged Attention; a failure to measure is treated as a note, not a fault, because it does not by itself decide the verdict. It is a single-server estimate against DeskTest.net, not a certified speed grade.

4. Named-service reachability

For Microsoft 365, Google, Zoom, and Slack, the check asks the independent desktest edge - an off-network vantage point - whether each service answers from the public internet. If the edge reaches a service, it is up right now; if the edge cannot, the service looks like a vendor outage (a Problem). Combined with layers 1 and 2 confirming your connection is fine, this is what separates "the service is down" from "your connection is down". Note the honest limit: because the probe runs from outside your network, it tells you whether a service is up, not whether this network specifically blocks a service that is otherwise up - if an app fails but shows up here, open it directly to rule out a local block or a browser content blocker.

5. Clock skew

It compares your system clock against a trusted timestamp from the edge, taking several timed samples and keeping the fastest (least network-skewed) one. Within about 2 seconds is OK; tens of seconds is Attention; a minute or more is a Problem. This layer is here because a badly wrong clock makes HTTPS certificates look invalid, so logins and secure apps fail in a way that looks exactly like a network outage - and the fix (turn on automatic time sync) is completely different.

How the verdict is decided

The verdict at the top of the page is not an average of the layers - it is an attribution, decided in priority order so the most actionable cause wins:

1. Nothing reachable - the internet could not be reached at all, so the break is at or before your own device or local network.
2. Clock badly wrong - the internet is reachable but the clock is off by a minute or more, which breaks secure connections; that is the lead cause even though the link is fine.
3. Sustained instability - reachable but the soak showed repeated loss or reconnects, so the fault is the link between you and the internet: likely your Wi-Fi or your ISP (see the honesty note below for why "likely").
4. A specific service - the connection is fine and stable, but a named cloud app is unreachable from the independent outside edge too, which points to a vendor outage rather than your connection.
5. Minor blips - mostly fine, with occasional Wi-Fi-style blips worth noting.
6. Healthy - every layer passed; if an app is still failing, it is that service or your account, not your connection.

What the browser cannot tell you

Trust is the whole point of this tool, so it is explicit about its limits rather than overclaiming:

• It cannot probe your router or gateway. A browser has no access to your local network hardware, cannot do ICMP ping, traceroute, or true packet-loss measurement, and cannot see the hop between your device and your router. So when the verdict says the problem is "likely your Wi-Fi or your ISP", that is inferred from the loss and jitter pattern measured to the internet edge - never asserted as if it were measured at the router. The single best way to split Wi-Fi from the ISP is to move to a wired connection and re-run: if wired is clean, it was Wi-Fi; if wired is still bad, escalate to the ISP.
• The soak measures browser-to-edge, not your LAN segment specifically. A clean result means the transport can sustain a live session right now; a bad result places the fault somewhere between this browser and the edge, which is usually - but not provably - your local link.
• Bandwidth is a single-server estimate. It is measured against one DeskTest.net server with throwaway bytes, so treat it as a sanity check, not a certified grade.
• Service reachability is measured from outside your network. The edge can tell you a service is up or down from the public internet, but it is not on your network, so it cannot see whether this network specifically blocks an otherwise-up service. That is why the tool tells you to open the app directly before blaming - or clearing - the network.

The ISP-ready report

When the run finishes, three buttons appear below the check:

• Copy report copies a plain-text report - the verdict, then every layer with its numbers (first-hop round-trip, packet loss and jitter, reconnects, bandwidth, per-service reachability, and clock offset) plus timestamps - ready to paste into a ticket.
• Send to my provider opens a pre-filled email containing that same report, with the verdict already in the subject line, so you can send it straight to your ISP or help desk.
• Run again clears the results and re-runs from scratch. When a layer needs attention, a "Run again" button also appears right under the verdict, so you can make the fix and re-test in one click.

A View report toggle shows the exact text the two buttons use, so you can read it before sending. The report includes your browser's user agent and the page origin, but no files, credentials, or business data. The numbers are exactly what an ISP or network admin will ask for.

White-label for IT teams

Two optional URL parameters let an IT team hand staff a branded, pre-addressed version of the check - no build step, just a link:

• ?org=<name> adds a banner naming the organization and stamps that name onto the report.
• ?support=<email> points "Send to my provider" at that address, so the pre-filled email is already addressed to your help desk. When a support address is set, the banner shows it too, so staff see exactly where the report goes.

Combine both in one link. For example:

https://desktest.net/connection-check/?org=Acme%20Property&[email protected]

opens the check branded for Acme Property, with "Send to my provider" pre-addressed to the help desk. The organization name is length-capped and only ever displayed; the parameters are read from the URL and never leave the browser except in the email the user chooses to send.

When to run it

Run the Connection Check the moment "the internet is slow" or "the app keeps disconnecting" comes up, before blaming any one thing. In under a minute it tells you which direction to look - your device, your Wi-Fi, your ISP, or the service - and produces a report to attach to the ticket. If a layer comes back with a problem, open the matching single-purpose tool below for the deep dive.

Related tools

The Connection Check is a fast attribution summary of several tools that each go much deeper. Open the one its verdict points you to:

• Network Test - reachability, DNS, WebSocket, captive-portal, latency, and jitter in detail.
• Speed Test - a fuller download/upload throughput measurement and video-call readiness.
• Socket Stability Test - a longer WebSocket soak for live-session reliability.
• SaaS Test - is it me or them, across more cloud services.
• Clock Test - a detailed system-clock accuracy check.
• Full Workstation Checkup - the broader browser, system, and network health dashboard.

See also About DeskTest.net and the DeskTest.net home.