Do not start with the package speed. Start with where the problem changes. Use the same device, the same task and one controlled change at a time. If moving closer to the router fixes it, that tells you more than another speed test. If nothing changes locally but the same problem appears every evening, that points you somewhere else.
Start here: three tests, about five minutes
Test while the problem is happening. Before restarting anything, capture one bad reading if you can. A reboot may clear the symptom and destroy the comparison you needed.
Test 1 — Turn Wi-Fi off
Repeat the exact slow task on mobile data.
- Still slow? Go to 8. Service or route and 9. One device only.
- Fine on mobile data? The home Wi-Fi, router or fixed Internet path remains in play. Continue.
Test 2 — Stand next to the router
Same device, same task, about one metre from the router.
- Problem mostly disappears? Go to 1. Weak Wi-Fi and 2. Wi-Fi congestion.
- Problem follows you? Continue.
Test 3 — Pause heavy traffic, then check loaded latency
Pause cloud backup, photo sync, large uploads and updates. If possible, compare latency while idle with latency during a sustained upload.
- Latency rises by more than about 100 ms under load? Go to 3. Queueing / bufferbloat.
- Pausing uploads fixes the experience immediately? Go to 4. Something is filling the line.
- No useful change? Use the symptom table below.
If the three tests did not settle it, route by symptom
| What you notice | Go directly to |
|---|---|
| Pages stay blank briefly, then load fast | → 5. DNS / initial connection delay |
| Bad most evenings, good early morning, repeated over several days | → 6. Upstream congestion |
| Several devices show repeatable loss or instability at different times | → 7. Line / equipment fault |
| One app or website is bad; unrelated services are normal | → 8. Service or route |
| One device is slow; another beside it is normal | → 9. Device-specific problem |
Nine common causes — only read the ones your test points to
1. Weak Wi-Fi where you actually use the device
A healthy Internet feed can arrive at the router and still fail in the bedroom. Around −67 dBm or better is a useful target for real-time Wi-Fi; below roughly −70 dBm, retries and interference matter much more. Confirm: the same device improves close to the router. Fix: move the access point into the open; add a well-placed access point or mesh node if the room is genuinely weak. A faster package will not fix this.
2. Wi-Fi congestion despite good signal
Strong bars do not mean clean airtime. In busy buildings, several networks may compete for the same channel. Confirm: signal looks good but Wi-Fi performance is erratic and improves on another band or over Ethernet. Fix: on 2.4 GHz use 20 MHz channels and normally 1, 6 or 11; on 5 GHz, use a clean channel supported by your equipment and local rules.
3. Queueing under load — bufferbloat
This is how a 500 Mbps line can feel broken. Bulk traffic fills a queue; downloads still run fast, while calls, games and small requests wait behind it. Confirm: idle latency is normal but rises repeatedly by roughly 100 ms or more during a sustained upload. Fix: if your router supports SQM/CAKE/fq_codel or a good adaptive QoS mode, shape slightly below the real line rate and retest. Around 85–90% is a common starting point, not a universal setting.
4. Something on your network is filling the line
Backups, cloud sync, security cameras and updates can make everyone else feel slow. Upload saturation is easy to miss on asymmetric plans. It can even hurt downloads because acknowledgements and other return traffic still need room to leave your network. Confirm: pause heavy transfers for two minutes and repeat the task. Fix: schedule or rate-limit the traffic before buying more bandwidth.
5. DNS or initial connection delay
The tell is a pause before anything starts, followed by a page that loads quickly. Confirm: compare several unrelated sites and DNS lookup timing if your tool exposes it. Fix: compare your provider's resolver with an alternative before switching permanently; a public resolver is not automatically faster.
6. Congestion farther upstream
If several devices are affected, local Wi-Fi stays healthy, and the same Internet-path degradation appears mainly in a repeatable busy window, the bottleneck may be outside the home. Confirm: run the same check at the bad time and at a quiet time on at least three days. One bad evening is an incident; the same pattern over several days is evidence.
7. Line, cable or equipment fault
Repeatable loss or instability across several devices and times deserves escalation. Confirm: rule out Wi-Fi where possible and check more than one reliable destination; one hop that ignores ping is not proof. Sustained packet loss around or above 1% is enough to become visible in many real-time applications.
8. The service or the route to it
If one service is bad while several unrelated services are normal — especially if the same service is still bad on mobile data — the whole home connection is unlikely to be the only cause. Check the service status and whether a VPN or unusual route is involved.
9. One device only
If a second device on the same Wi-Fi, in the same place, performs normally, investigate the first device before the network. Start with VPN/private-relay settings, background updates, battery restrictions, storage pressure and the affected app. Restart last, after you have captured the comparison.
Practical troubleshooting ranges
These are reference points, not service-level pass/fail limits. Different applications, targets and networks tolerate impairment differently.
| Measure | Generally comfortable | Investigate when repeated |
|---|---|---|
| Idle latency | < 30 ms | > 80 ms |
| Latency increase under load | < 30 ms | > 100 ms |
| Jitter | < 10 ms | > 30 ms |
| Packet loss | < 0.5% | ≈ 1% or more |
| DNS lookup | < 50 ms | > 150 ms |
| Wi-Fi signal | ≈ −60 dBm or better | Below ≈ −70 dBm |
Build a case your provider can actually use
Do not send “Internet is slow.” Send the pattern, the time and what you already ruled out.
Example: “On 18, 19 and 20 August between 20:30 and 22:00, three devices showed high latency and packet loss beyond the local router. Around 06:00 the same checks were normal. Wi-Fi at the test point was strong. I have the readings from each run.”
If support replies that the speed test is fine, clarify that you are reporting latency, loss or instability, not missing Mbps. If the problem is consistently at 21:00, ask them to check line statistics and upstream utilisation for that window before relying only on a technician visit at 11:00; a clean daytime visit does not explain an evening-only fault.
Diagnostix360 can produce a customer report and a technical report from the same run. The report does not assign blame; it gives support something more useful than a general complaint.
Frequently asked questions
Should I restart the router first?+
Not before one useful measurement if the fault is intermittent. Restart after you capture the bad condition, then compare the same test again.
A speed test says I get full speed. How can it still be slow?+
Throughput is only one property. Loaded latency, jitter, loss, Wi-Fi quality and destination-specific problems can all hurt the experience while Mbps remains high.
It is only bad at night. Is that my ISP?+
Not automatically. First rule out evening activity inside the home, such as backups, uploads and streaming. If Wi-Fi remains healthy and the same Internet-path degradation appears during the same busy window on several separate days, compare it with a quiet-time reading and take that pattern to your provider.
Should I upgrade my Internet package?+
Only when you can show that capacity itself is the constraint. More Mbps will not repair weak Wi-Fi, loss, high latency, poor routing or a problem on one device.
Bottom line
Preserve the bad moment, change one thing, and follow the first comparison that changes the symptom. That is faster than reading a generic checklist — and it gives you evidence you can use.
Check the connection where the problem happens
Run Diagnostix360 on the same Android phone, in the same place, while the problem is present. Make one change, then run the check again.
This article is general troubleshooting information, not professional, contractual, legal, security or SLA advice. The ranges are practical references, not certified pass/fail standards. Results vary with the target, application, device and network. Diagnostix360 describes conditions measured at that moment; it does not assign responsibility or replace provider-side or professional diagnostics where those are required. Read detailed reports before sharing them. See the Terms of Use and Privacy Policy.