Connection Stability Test Guide

A reference for the DeskTest.net Connection Stability Test. This tool holds one WebSocket open to the edge for about 45 seconds and pings it on a schedule to catch a link that is flaky over time - the transport fault behind long-running sessions that "randomly disconnect" while a one-shot network check looks perfectly fine.

Open the Connection Stability Test →

What does this test check?

It measures whether a WebSocket connection stays healthy over time, not just whether one can be opened. Three steps run in order:

1. Connect. Opens a single wss://edge.desktest.net connection and confirms the upgrade completes within 8 seconds. If it never opens, the run stops here - there is nothing to monitor, and the fault is basic WebSocket reachability, not stability.
2. Monitor. Holds that socket open for about 45 seconds and sends a sequenced ping (desktest-stability-1, -2, and so on) every 1.5 seconds. The edge echoes each ping back; the round-trip is timed with performance.now(). A ping with no echo within 5 seconds is counted as lost. If the socket closes unexpectedly, the tool records the drop and automatically reconnects, so it can count how often the link fails and recovers. A live progress bar and a running readout (sent, echoed, missed, reconnects, last and average round-trip) update as it goes.
3. Assess. Rolls the run into one verdict - stable, occasional blips, or dropping - from ping loss, reconnect count, unexpected closes, socket errors, and round-trip spikes.

The scope is deliberately honest: this is a browser-to-edge measurement across the public internet. It cannot single out your local LAN segment, and a browser sandbox cannot send ICMP pings, use raw sockets, or measure true packet loss. What it can do is prove whether the transport can sustain a long-lived socket right now - which is exactly what long-running web apps depend on.

How is this different from the Network Test?

The Network Test is a one-shot snapshot: it opens a WebSocket once, sends one echo, and reports whether it worked. That answers "can this workstation get out at all?" It will pass on a link that opens fine but drops every twenty seconds.

This test answers a different question: "will a connection stay up?" It keeps the socket open and watches it, so it catches faults that only appear with time - a Wi-Fi client roaming between access points, a VPN that resets idle sockets, a firewall enforcing a short WebSocket idle timeout, or interference that drops a few packets a minute. Run the Network Test to triage a "page won't load" ticket; run this one to chase a "keeps disconnecting" ticket.

When should I run this?

• "It keeps disconnecting" tickets. A scanner session, a call, or a dashboard drops every few minutes but a normal connectivity check looks fine. This is built for exactly that.
• Before a long scanning or deposit session. Remote-deposit and scanner integrations (FIS WebScan, Topaz SignalR) hold a socket open for the whole session. If this test shows drops, the session will too.
• Teams, Zoom, or softphone call quality. Real-time media tolerates latency but not jitter and drops. A "blips" or "dropping" result here explains choppy calls.
• Remote desktop / VDI over the browser. Web-based RDP and VDI clients freeze and reconnect on an unstable transport.
• Comparing wired vs Wi-Fi, or with vs without VPN. Run it twice under each condition and compare the loss and reconnect counts.

Why "keep this tab in the foreground"?

Browsers aggressively throttle timers in background tabs to save battery - a tab that is not visible may only get to run its setInterval once a minute or less. If you switch tabs, minimise the window, or let the screen lock during the run, the pings stop firing on schedule and the tool records them as missed. That would look like a dropping connection when the network was fine.

Reading the verdict

The verdict panel at the top gives the headline, a likely cause, and a recommended next step. The three step rows below show the connect timing, the full run tallies (with an expandable event timeline), and the assessment. Here is what each verdict means:

Copy Diagnostic Report produces a plain-text summary: timestamps, the connect handshake time, every tally (sent, echoed, missed, closes, errors, reconnects), the round-trip statistics, and a timestamped event timeline of every drop, reconnect, error, and lost ping. Paste it into a ticket or an email to the network team. Send to your IT drops the same text into a pre-filled email.

Reading the numbers

• Ping loss % - missed pings as a share of pings sent. A few tenths of a percent is noise; sustained loss is the clearest sign of an unstable link.
• Reconnects - how many times the socket dropped and the tool reopened it. Even one reconnect in 45 seconds is worth noting; two or more is a dropping link.
• Round-trip average / p95 / max - typical and worst-case echo time. A low average with a high max means the link is usually fast but spikes.
• Jitter - the mean variation between consecutive round-trips. High jitter is what makes calls and remote desktop stutter even when the average looks fine.

Fixing a flaky link

When the verdict is "occasional blips" or "dropping", work through these in order. They are ordered by how often they are the real cause.

1. Re-run with the tab kept in front. Rule out background-tab throttling first - it is the single most common cause of a falsely bad result. Do not switch tabs or lock the screen during the run.
2. Move from Wi-Fi to wired. Flaky Wi-Fi - weak signal, roaming between access points, or 2.4 GHz interference from microwaves, cordless phones, and neighbouring networks - is the most common real cause of this pattern. A wired connection removes all of it.
3. If on Wi-Fi, improve the radio link. Move closer to the access point, prefer the 5 GHz band, and check whether the workstation is clinging to a distant access point instead of roaming to a nearer one.
4. Disconnect the VPN and re-run. Congested or distant VPN egress adds jitter, and some VPNs reset long-lived or idle sockets on a timer. Comparing with and without the VPN isolates it quickly.
5. Check for a short WebSocket idle timeout. Some firewalls, load balancers, and reverse proxies close a WebSocket that has not sent data within a fixed window. This shows up as regular, evenly-spaced reconnects.
6. Look for competing traffic. A backup, a large download, or a video call on the same workstation or link can starve the socket. Re-run when the workstation is otherwise idle.
7. Confirm with a second data point. Run the Network Test to check latency, jitter, and reachability to public endpoints, and note whether its jitter reading is also high.

For IT admins

The test opens one outbound wss:// connection to edge.desktest.net (DeskTest.net's own Cloudflare Worker, a WebSocket echo on port 443) and keeps it open for about 45 seconds. For a clean run, your egress must both allow the WebSocket upgrade and not tear down an idle-ish long-lived socket:

• Allow the upgrade. If step 1 fails outright, the wss:// upgrade is being blocked - common on stricter Fortinet, Sophos, Palo Alto, Zscaler, and Netskope rulesets that do not pass HTTP upgrade frames by default.
• Watch idle timeouts. Regular, evenly-spaced reconnects usually mean a firewall, load balancer, or reverse proxy is enforcing a WebSocket idle timeout shorter than the ping interval used by the real app. The tool pings every 1.5 seconds, so it will usually stay under a timeout that the real app trips - meaning a clean run here does not rule out a longer idle timeout hurting a quieter app.
• TLS-intercepting proxies. A proxy that terminates and re-originates TLS may mishandle WebSocket frames or reset the connection under load, showing up here as unexpected closes and errors.

The result is scoped browser-to-edge. It confirms the path from this workstation to the public internet can sustain a long-lived socket; it cannot, on its own, tell you which hop on that path is at fault. Pair a "dropping" result with the Wi-Fi vs wired and VPN on/off comparisons above to localise it. The copyable report - with its timestamped event timeline - is a paste-ready record for a change ticket.

The page has no third-party scripts, no analytics, and no fonts or images loaded from a CDN, so there is nothing extra to allow-list for it to render. It needs only desktest.net (to load) and edge.desktest.net over wss:// and https:// (to test).

Behind the scenes

The whole run uses the browser WebSocket API and nothing else. Each ping is a short string, desktest-stability- followed by a sequence number; the edge Worker sends back exactly what it receives. A pending map records the send time for each sequence number, and when the matching echo arrives the round-trip is the performance.now() delta. Any sequence number still outstanding after 5 seconds is swept and counted as lost.

When the socket closes unexpectedly before the window ends, the tool records the close, waits a second, and reopens - each successful reopen increments the reconnect count. Round-trip spikes are counted against a threshold that adapts to the link (the larger of 150 ms or three times the median round-trip), so a genuinely slow-but-steady link is not falsely flagged. The socket and all timers are closed the moment the window ends, and again on Reset or when you leave the page, so nothing is left running in the background.

No payload data leaves the browser except the literal ping tokens. There is no telemetry to DeskTest.net, no analytics beacon, and no tracking. View the page source to confirm the endpoint and the exact ping payload.

Related

• Connection Stability Test - the monitor itself
• Network Test - one-shot reachability, DNS, and WebSocket egress check
• Network Test Guide - the companion snapshot check explained
• Sitelink Test Guide - end-to-end reachability for a specific URL
• About DeskTest.net
• DeskTest.net home

Elsewhere on the web:

• Cloudflare Speed Test - throughput and latency under load, including a loaded-latency figure that complements this stability read.
• websocket.org echo test - a bare WebSocket echo you can point at your own endpoints.