Measurement tool

Connection Stability Test

Throughput tells you how fast the line can go. Stability tells you whether it stays usable. This monitor probes the network once a second and reports the spread.

Stability monitor

One probe per second. Failures are counted, not smoothed away.

idle
Run length

Median

—ms

Jitter

—ms

Best

—ms

Worst

—ms

No-failure rate

—

Probes

—

Round-trip time over the run (ms)

Ready. Nothing is measured until you start.

What stability testing adds

A single speed test averages over 15–20 seconds and hides short interruptions. Many real problems are intermittent: a router that drops packets when it gets warm, a wireless link that retries whenever a microwave runs, an ISP segment that congests every evening.

This monitor sends one small request per second for 45 seconds and records every result. Failures are counted, not smoothed away, and the chart makes spikes visible.

How to read the report

  • Failed probes — requests that never completed. A single failure in a long run can be a transient timeout; repeated failures indicate a real problem.
  • Median vs worst — if the worst round trip is several times the median, the line has spikes.
  • Jitter — the average change between consecutive probes. This is the number that predicts call quality.
  • Best — the fastest round trip observed. Compare it with your median to see how much headroom the path has.

Run the monitor while nothing else is happening, then again during a video call or a large download. The difference between the two runs is what your router does under load — the bufferbloat test quantifies that separately.

Choosing 45 or 90 seconds

Both runs use the same method — one probe per second — so the only difference is the window. Forty-five seconds is enough to catch a constant problem and is the right default when you are comparing two setups quickly.

Use the 90-second run when the fault is occasional rather than constant. Run it while you reproduce the problem: with the call open, during a download, or at the time of day when things usually go wrong. Then read the pattern rather than the average:

  • Evenly spaced points — a healthy line.
  • Repeating spikes at a regular interval — usually a device waking up and saturating the link, or a Wi-Fi scan cycle.
  • Gradual climb — a queue filling, often from a background upload.
  • Failed probes — note when they happen and compare with what else was running.

What neither window can tell you is which hop in the path is at fault, or how UDP traffic behaves. A per-hop view needs a traceroute-style tool at the operating-system level. This page gives you the evidence that a problem exists and roughly how often.

Common causes of an unstable line

Wireless interference, a saturated uplink, old coaxial or telephone wiring, a modem that is overheating, and ISP-side congestion are the usual suspects, in roughly that order for home connections. For a structured diagnostic sequence, see the troubleshooting guide.

Questions about this tool

Why do some probes fail?
A probe can fail because of packet loss, a Wi-Fi retry that exceeded the timeout, or a brief moment of congestion. Isolated failures are normal; a pattern is not.
How long should I monitor?
45 seconds catches most short-term problems. Switch the run length to 90 seconds when the fault is occasional rather than constant — a call that drops every ten minutes, a game that lags in bursts, or something that only happens at a particular time of day.
Does monitoring use much data?
No. Each probe is a few hundred bytes; a full 45-second run is well under one megabyte.
Does this measure packet loss?
It measures request loss, which is related but not identical to the packet loss a game or call would see. The packet loss page explains the difference.