I’m trying to document an unreliable connection before contacting my ISP again. Their basic line check shows everything as normal, but during regular use pages stall, calls break up, and downloads briefly stop. I see the same behavior on a wired device after restarting the modem, so it does not match the stable service I expected.
Do others see this kind of mismatch between ISP tests and actual use, and what records helped demonstrate that the connection was bad?
Record whether the wired device is connected directly to the modem or still passes through your router. The ISP may blame local equipment unless you can show the problem occurs with one computer, Ethernet, Wi-Fi disabled, and the router temporarily removed from the path.
Run a continuous ping test for a few hours and save the output with timestamps. If possible, ping both your ISP’s first gateway and a reliable outside address. That helps separate a local line problem from a wider routing issue. Save each internet speed test result too, but packet loss and latency spikes usually explain stalls and broken calls better than download speed alone.
Keep a short log showing the exact time, what failed, and how long it lasted. Screenshots of modem signal levels and event logs can help as well. An ISP line check is often just a snapshot, so an intermittent connection can look normal during the test. A few days of timestamped evidence gives support a specific window to investigate instead of another generic “restart the modem” response.
A gateway that ignores ping packets while normal traffic passes is very different from a line that drops everything, so don’t rely too heavily on first-hop ping loss. Test two or three outside addresses at the same time and note whether all of them fail together. If they do, give support the exact outage times and ask them to check modem registration or signal history for those windows. That is harder to dismiss as a single server or ICMP issue.
You probably won’t get a single test that “proves” the ISP is at fault. What confused me at first was that restarting the modem can erase exactly the evidence support needs. Before rebooting, photograph the status pages showing uptime, corrected and uncorrected errors, disconnects, and signal levels. Then capture them again after a bad period so there is a visible change.
The direct Ethernet test mentioned above still matters, but leave that setup running long enough for the fault to happen. A clean ten-minute test does not say much about a connection that fails twice a day. While testing, avoid cloud backups, game updates, and other heavy traffic because the ISP can reasonably blame congestion inside your home.
When it fails, note whether the modem’s connection light changes and whether its local settings page still opens. If the modem page works but several outside services stop together, that is useful. If even the modem page becomes unreachable, the modem, cable, power supply, or Ethernet connection may be involved.
I would send support a small set of clear examples rather than hours of raw ping output: exact time, duration, wired setup, what stopped working, and the modem readings before and after. Ask them to check historical signal levels and disconnect records for those exact times. That gives them something specific to compare against instead of another snapshot taken while the line happens to be behaving.
Don’t reboot the modem right before you call in. That erases the error counters and uptime, which is usually the only hard evidence support can’t wave away. Grab those screenshots first, then reboot if you have to.
Stop trying to build a courtroom case. You only need enough evidence to force an escalation and a technician visit.
The screenshots and timestamps people mentioned are useful, but support can still blame customer equipment. If you own the modem, temporarily using an ISP-supplied unit may be worth the rental charge because it removes their easiest excuse. If their modem shows the same failures, ask them to replace it or test the line at the outside connection point. A technician’s meter readings at that point carry more weight inside the ISP than pages of ping results from your computer.
Keep every ticket number and give them three or four exact failure windows. Use direct Ethernet, but replace the Ethernet cable too. Otherwise they can reasonably point at the cable or network adapter. Tell support plainly: “This occurred with Wi-Fi and the router removed, using your modem, at these times.” Then ask them to check signal history, modem resets, upstream transmit levels, and neighborhood-node issues during those windows.
@kevin_git is right about saving the modem data before rebooting, but don’t spend weeks collecting perfect evidence. Once you have repeat failures under a stripped-down setup, request a truck roll. If the first technician only swaps hardware and leaves, keep the same ticket history going and push for line maintenance rather than starting over with another basic phone script.
Ping loss alone does not prove the connection is dropping. Some routers deprioritize ICMP, and support can dismiss that result even when the timestamps look convincing. @jackthebit is right about testing multiple destinations, but include normal traffic in the test so you are measuring the same kind of failure you actually notice.
Set up a wired computer and run three checks at the same time:
Make sure the computer’s date and time are synchronized before starting. If the local ping stays normal while both public pings and the HTTPS request fail at 8:42:17 PM, that is much harder to blame on Wi-Fi, DNS, or a slow website. If the local ping fails too, investigate the Ethernet cable, network adapter, router, modem, or power before claiming it is the ISP line.
DNS deserves its own quick check. During the next stall, try opening a site that is already loaded, making a fresh DNS lookup, and reaching a known IP address. If calls and existing downloads continue but new pages will not start, DNS may be the problem rather than the physical connection. If calls break up, downloads freeze, and several public targets fail together, the evidence points toward a broader interruption.
Keep the final evidence short. Pick three clear incidents and show about a minute before and after each one. Include the local control, public tests, HTTPS result, and the exact time. Huge log files tend to get ignored. A compact sample lets the technician compare your failures with DHCP events, modem re-registrations, signal changes, or upstream problems.
Do not connect a computer directly to a modem for hours unless its firewall is enabled and the operating system is updated. Removing the router is a useful isolation test, but it should be controlled rather than treated as the default setup. Once the same simultaneous failures appear with local connectivity remaining stable, send those timestamps with the ticket and ask for escalation based on intermittent packet transport failure, not “slow speed.”
A line that fails while idle is a different case from one that falls apart only when someone is uploading. Pages stalling and calls breaking up can come from upstream saturation or bufferbloat even though the ISP’s basic line test looks normal.
Check your router’s traffic graph during each incident. If the connection fails with almost no traffic, document that. If it only fails during uploads, reproduce it with one wired computer and a controlled upload, then show the ISP the resulting latency and packet loss. That distinction can prevent them from dismissing the case as ordinary household congestion.