Why Documentation Changes the Outcome
ISP support conversations go one of two ways. In the first version, a customer says “my internet has been slow for three weeks” and the support agent reboots the modem remotely, closes the ticket, and the problem comes back in two days. In the second version, a customer says “I have speed test results from 14 evenings showing 60 Mbps on a 500 Mbps plan consistently between 7 and 9 PM, an MTR report showing 6% packet loss at your first router during the same window, and a modem event log showing recurring T3 timeouts at those times” — and the ISP dispatches a line technician who finds a corroded tap on the street and fixes it.
Documentation transforms a vague complaint into a technical support case that engineers can act on. This guide covers what to collect, how to collect it, and how to present it.
The Documentation Checklist
| Evidence Item | Tool / Source | Minimum Useful Amount |
|---|---|---|
| Speed test results | speedtesthq.com, Cloudflare speed.cloudflare.com | 3 tests per session, at least 2 sessions (peak and off-peak) |
| Latency/packet loss over time | PingPlotter (free tier), MTR | At least 1 hour of continuous monitoring during the problem window |
| MTR report to 1.1.1.1 | mtr --report -c 100 1.1.1.1 | Run 3 times during the problem period; save each output |
| Modem event log | 192.168.100.1 → Event Log | Full log screenshot with timestamps; note any T3/T4 timeout entries |
| Modem signal levels | 192.168.100.1 → Signal/Status | Screenshot of downstream power, upstream power, SNR, corrected/uncorrected errors |
| Connection details | Your notes | Connection type (Ethernet/Wi-Fi), which device, router model, modem model |
| Problem timeline | Your notes | When it started, how often it occurs, exact times of worst episodes |
How to Run PingPlotter for Continuous Documentation
PingPlotter is the most valuable tool for documenting intermittent problems because it graphs latency and packet loss over time, automatically. Download PingPlotter (free version works for this), set the target to 1.1.1.1, and set the trace interval to 5 seconds. Add a second target of your router's gateway IP (usually 192.168.1.1) to see LAN vs internet separately. Let it run for the full problem window — 2–3 hours during the time the problem usually occurs.
When the problem appears, the graph will show the spike in latency or the packet loss appearing at a specific hop. Export the graph (File → Save Session, or right-click → Export as Image) with timestamps visible. This image is the most compelling single piece of evidence you can provide — it shows a visual timeline of the problem, the affected hops, and the duration.
Collecting the MTR Report
Run MTR during the problem period, not after it resolves. If the problem only occurs in the evening, run MTR at 8 PM, not at 10 AM. The output needs to reflect the actual failure conditions.
# macOS / Linux (save to a text file)
mtr --report --report-cycles 100 1.1.1.1 > mtr-report.txt
# Also run against 8.8.8.8 for comparison
mtr --report --report-cycles 100 8.8.8.8 >> mtr-report.txt
# Windows: download WinMTR (free), set host to 1.1.1.1, run 100 cycles, export as textThe report shows each hop between you and the destination. Look for the hop where packet loss first appears and does not recover in later hops. That is the location of the problem. A hop that shows loss but subsequent hops are clean is usually just a router deprioritizing ICMP — not real loss.
Writing the ISP Ticket Summary
When you open or follow up on a support ticket, structure your summary to get past the script:
- Problem description: “I am experiencing slow speeds and packet loss consistently between 6 PM and 10 PM, on my [plan speed] plan. This has been recurring for [X weeks].”
- What I have ruled out: “I have tested on a wired Ethernet connection directly to the modem, bypassing my router and all home Wi-Fi. The problem persists on a direct modem connection.”
- The data: “My speed tests show [X] Mbps on Ethernet during peak hours, against a [plan speed] plan. My MTR report shows [X]% packet loss at hop [N], IP [address], consistently during these hours. My modem event log shows T3 timeouts at [time stamps].”
- The request: “I am requesting a line technician to inspect the outside plant, specifically the tap and the drop cable. I do not believe the problem is in my home equipment based on the direct modem test results.”
Frequently Asked Questions
How long should I document before calling?
Document through at least two to three occurrences of the problem — enough to show a pattern rather than a one-time event. For intermittent problems, a week of PingPlotter data that shows the same pattern recurring on weekday evenings is far more compelling than one bad day. For a persistent problem (always slow), three test sessions over two or three days with consistent results is sufficient to make a strong case.
Does the ISP have to accept my documentation?
They cannot reject factual data. An ISP support agent may not know what to do with an MTR report, but asking to escalate to a network engineer — and providing the report with a clear summary of what it shows — typically gets the ticket to someone who can interpret it. If the first-level agent dismisses your data, ask to have the ticket notes include the MTR results and request escalation to technical support or network operations.
What if my modem event log shows nothing unusual but speeds are still slow?
Clean modem logs with slow speeds usually point to ISP-side congestion rather than a line hardware problem. Congestion happens in the neighborhood node, in the upstream aggregation equipment, or in the ISP's transit links to other networks — none of which shows up in your modem's event log, because those devices are all upstream of your modem. The best evidence for congestion is speed test results showing consistent degradation at specific times of day, correlated with an MTR report showing increased latency or loss at hops further into the ISP's network. Present this time-correlation specifically to the ISP.