How to diagnose intermittent network problems

Intermittent network problems are easiest to diagnose when measurements are already running before the symptom appears. Compare the affected endpoint with another endpoint, test the local gateway separately from public targets, and separate DNS and application checks from basic IP reachability. The goal is to identify the first boundary where behavior changed.

Avoid starting with a reboot. Restarting the router or device may restore service, but it also removes state and makes the fault harder to explain. Capture the time, affected devices, and available evidence first whenever practical.

Recognize the symptom precisely

"The Internet dropped" can describe several different failures. Record what the user actually observed:

• every service stopped, or only one website or application;
• one device was affected, or every device at the location;
• an existing call or stream broke, or only new connections failed;
• names stopped resolving, or direct IP connections also failed;
• the connection became slow, or it became completely unavailable;
• the symptom lasted continuously, or appeared in short bursts.

This description determines which measurements should agree if a theory is correct.

Understand latency, packet loss, and jitter

Signal	What it describes	What a change may feel like
Latency	Time for traffic to travel to a target and back	Slow page starts, input lag, delayed calls
Packet loss	Traffic that does not reach the measured destination or return	Freezes, retries, broken calls, reduced throughput
Jitter	Variation in delay between measurements or packets	Uneven audio or video, unstable interactive sessions

These are related but not interchangeable. A path can have high yet stable latency with no loss. Another can have low average latency but damaging bursts of loss. Averages can also hide a short severe event, so inspect the timeline and individual fault window rather than relying only on a daily summary.

Build measurements across failure boundaries

Use targets that let one hypothesis fail while another remains possible:

Check	Boundary it tests
Local gateway	Endpoint, Wi-Fi or Ethernet, access point, switch, local router
Stable public IP	Router WAN, modem or ONT, ISP access, broader Internet path
DNS resolution	Resolver, forwarding, filtering, DNS transport, answer correctness
TCP connection	Reachability of a specific service and port
TLS handshake	Certificate, protocol negotiation, interception, TLS endpoint
HTTP response	Application and reverse-proxy behavior after a connection succeeds
Endpoint health	Local resource pressure, interface throughput, uptime or restart

Measure at least the gateway and one public target from the same endpoint. If possible, run the same checks from another device or from an always-on point near the gateway.

Step 1: establish scope by comparing endpoints

Ask whether the symptom appears on:

• one device only;
• every device on one Wi-Fi access point or VLAN;
• wired and wireless devices at the same site;
• one site but not another;
• every site reaching the same remote service.

If one endpoint fails while another endpoint on the same network remains healthy, investigate the endpoint and its local link first. If all endpoints at one site change together, move the investigation toward the shared gateway or uplink. If independent sites fail against one service at the same time, the remote service becomes a stronger candidate.

Step 2: separate the local gateway from the Internet path

Compare gateway and public-target timelines over the exact fault window:

• Gateway and public target degrade together on one device: start with that device's Wi-Fi or wired link, interface, and access point association.
• Gateway remains healthy but public targets degrade on several devices: inspect the router WAN, modem or ONT, ISP link, and upstream path.
• Gateway degrades for every local device: inspect router load, switching, cabling, access-point backhaul, power, or a local broadcast problem.
• Only one public target degrades: compare another independent public target before blaming the whole Internet connection.

Gateway replies are diagnostic evidence, not an absolute guarantee. Some devices limit or deprioritize ICMP while forwarding ordinary traffic normally. Confirm suspicious patterns with service-layer checks.

Step 3: test Wi-Fi and wired paths separately

When a wireless endpoint is affected, compare it with a wired endpoint and, if available, with another Wi-Fi device near the same place. Look for changes in signal, link rate, interface state, roaming, and gateway quality.

A Wi-Fi problem is more likely when the affected device loses gateway quality while a wired Agent remains stable. The evidence is weaker if both wired and wireless devices lose public targets while both still reach the gateway well; that pattern points beyond the local radio link.

Step 4: separate DNS from basic reachability

DNS failures often look like a complete outage because applications begin with a name lookup. Compare a public-IP check with an explicit DNS check:

• IP reachability works while DNS fails: inspect the configured resolver, router forwarding, filtering, split DNS, encrypted DNS path, or answer policy.
• Both fail together: DNS may only be a downstream symptom of a wider network fault.
• One domain fails while other DNS queries succeed: inspect authoritative DNS, caching, filtering, or the domain's own configuration.

Do not treat a successful cached lookup as proof that the resolver was healthy throughout the incident. Continuous checks preserve the failure window better than an ad hoc query after recovery.

Step 5: walk up the application stack

If basic reachability remains healthy, test the service in layers:

1. Can the endpoint resolve the expected name?
2. Can it establish TCP to the required port?
3. Can it complete the TLS handshake?
4. Does the HTTP service return an expected response?

The first failing layer narrows the next investigation. A valid ICMP reply does not prove that a port is open, TLS negotiation works, or the application is healthy. Conversely, a service may work while ICMP is filtered.

Step 6: correlate endpoint health

Only-one-device problems are not always network faults. Compare the incident window with CPU, memory pressure, disk activity, uptime, interface throughput, and process or connection evidence where locally permitted.

For example, an endpoint may show slow DNS and HTTP checks because it is heavily loaded, its interface is saturated, or a local proxy or security product is intercepting traffic. If gateway quality from another device remains normal, that local evidence matters more than the site's aggregate status.

Step 7: use path diagnostics carefully

A path trace can show where replies stop or latency begins to rise, but it does not by itself identify the faulty operator or device. Routers may not answer diagnostic packets, return paths may differ, and a slow intermediate hop is not necessarily harmful if later hops remain healthy.

Path evidence is most useful when it is captured automatically during the fault and compared with the same target's normal path. Look for a meaningful change that aligns with end-to-end loss or latency, not merely one silent hop.

Step 8: verify recovery and preserve evidence

Do not close the investigation at the first successful check. Record when each layer recovered and whether it recovered in a useful order: gateway first, public reachability next, DNS next, then the application, for example. A short stable period after recovery helps distinguish a real resolution from another brief fluctuation.

Keep the incident timeline, measurements, path diagnostics, and any change made during the fault. This evidence makes repeated incidents comparable and can turn an ISP, vendor, or internal support conversation from "it was slow" into a specific time window and failure boundary.

Common diagnostic mistakes

• Testing only after recovery. The normal result does not describe the fault.
• Watching only one target. A target-specific failure can look like a site outage.
• Using only averages. Brief loss bursts and jitter can disappear inside a long summary window.
• Assuming ping equals application health. DNS, ports, TLS, and HTTP can fail independently.
• Rebooting before recording evidence. The restart changes the system you are trying to explain.
• Collecting from only the Server. A central viewpoint cannot reveal every endpoint or Wi-Fi difference.
• Treating traceroute as proof of ownership. It is path evidence, not a root-cause verdict.

Using NetTact for this workflow

Place Agents at the gateway or always-on host, on an affected user device, and at independently failing remote sites. Configure the same gateway, public, DNS, and application targets where comparison is useful. NetTact keeps the measurements in one history and connects confirmed faults, precursor fluctuations, available path diagnostics, and recovery into incidents.

Start with home and small-network monitoring, then choose NetTact Desktop for one computer or self-host NetTact Server for several measurement points. Agent collection and target access remain bounded by the local permission policy.

Related standards

For precise terminology, see the IETF metrics for round-trip delay, one-way packet loss, and IP packet delay variation. RFC 1812 also describes why routers may rate-limit ICMP error messages, one reason diagnostic replies must be interpreted alongside end-to-end service behavior.