Diagnose an unstable internet connection

Common signs of an unstable connection

These are observations, not diagnoses. A symptom can result from your device, Wi-Fi, network congestion, a remote service, or other conditions along the route.

• Sudden latency spikes: a few round-trip readings rise well above the surrounding results.
• High jitter: measured response times change noticeably between successful readings. See What Is Jitter? for how PingWatch estimates it.
• Intermittent probe failures: some application-level HTTP or WebSocket checks do not complete successfully. A failed probe is not confirmation of packet loss.
• Consistently elevated latency: successful responses repeatedly take longer than expected for the task or destination being tested.
• Connection interruptions: one or more applications become temporarily unavailable or lose an active session.

A chart from one endpoint can show when its measured response changed, but it cannot establish which network component caused that change.

A step-by-step troubleshooting process

1. Check the scope. See whether one application, multiple services, one device, or several devices are affected. A problem limited to one service may involve that service or its route; it does not rule out a local issue.
2. Check the local connection. Confirm Wi-Fi signal and router connection, or reseat an Ethernet cable and check its link status. This can reveal a local connection issue but does not test every segment beyond your network.
3. Compare idle and loaded conditions. Run the same check when little else is using the connection, then during normal activity. If results change under load, competing traffic may be relevant; the comparison does not identify exactly which device or network queue is responsible.
4. Review background activity. Look for large uploads, downloads, cloud sync, streaming, or updates on your devices. Pause nonessential transfers temporarily if appropriate, compare, then resume them.
5. Restart equipment when appropriate. If you can safely interrupt service, use the router or modem's normal restart procedure. This may clear a temporary state, but a restart is not a diagnosis. Avoid factory resets unless you know how to restore configuration.
6. Compare destinations carefully. Repeat the same endpoint for a like-for-like comparison. A different destination follows a different route and may have different server conditions, so it is useful context—not an equivalent baseline.
7. Collect repeatable measurements. Record the test mode, endpoint, time, connection type, visible latency changes, jitter, and completed or failed probes. Repeat under comparable conditions. A browser test describes its measured exchange; it cannot prove the cause of a symptom.
8. Contact your ISP if the issue persists. Share timestamps, affected services/devices, wired versus Wi-Fi comparisons, repeated results, and any relevant service notices. These observations can help the investigation but are not definitive proof that the provider is at fault.

Compare Wi-Fi with Ethernet

If available, test the same device and PingWatch mode over Wi-Fi and a wired Ethernet connection, keeping the endpoint and other conditions as similar as practical. If readings become more consistent on Ethernet, wireless signal or interference may be worth investigating. If they do not, that still does not locate the issue: the router, device, route, endpoint, or other factors may contribute.

Ethernet does not guarantee lower latency or eliminate jitter; it simply removes the Wi-Fi radio link from that particular comparison. Results can also vary with cable, adapter, router port, and network load.

How to interpret PingWatch results

• Average latency: the arithmetic mean of valid successful round trips. A few high values can pull it upward.
• Median latency: the middle successful reading (or midpoint of the two middle readings). It is less influenced by a small number of extreme values than the mean.
• P95 latency: the 95th percentile of valid successful readings, calculated using linear interpolation at rank (n − 1) × 0.95. It describes the upper portion of this session's measurements, not a guaranteed worst case.
• Jitter: PingWatch's mean absolute change between adjacent successful readings in their collected order. It is a simple variation estimate, not RTP jitter. See the jitter guide.
• Connection Quality Score: a 0–100 product-defined heuristic combining latency, jitter, spike-based stability, and successful probe rate. It is not a standardized networking benchmark or performance guarantee.
• Connection Stability Timeline: classifies the observed probe sequence, preserves detected spikes and failed probes, and estimates stable/unstable time only where adjacent observations support it. It does not verify connectivity continuously between probes.
• Lag spikes: after five successful readings, PingWatch flags a reading at least 50 ms above and at least twice the median of up to 20 recent successful readings. Consecutive flagged readings belong to one incident. This is a product detection rule, not a diagnosis.
• Failed monitoring probes: unsuccessful application-level HTTP or WebSocket checks. They may have several causes and are not necessarily equivalent to network packet loss.

PingWatch measures browser-to-selected-endpoint HTTP or WebSocket round trips, not ICMP ping, bandwidth, or every route you use. For more details, read Ping vs. Latency.

When should you contact your ISP?

Contact your provider when the problem is repeated, affects more than one device or service, persists after basic local checks, or coincides with a reported service issue. If your provider offers its own diagnostics, use those as well.

Before contacting support, collect the dates and times, affected devices and applications, whether the test used Wi-Fi or Ethernet, repeatable results to the same endpoint, and what changed when the network was idle or under load. Include relevant router status indicators or provider error messages. Be clear that PingWatch results are browser-to-PingWatch observations, not proof of provider responsibility or confirmed packet loss.