The first thing I usually hear when I arrive on site is: “The Internet has been slow all week.”
Sometimes they’re right. Usually they aren’t.
I’ve walked into offices where everyone was convinced the ISP was the problem, only to find a failing network switch. I’ve seen slow applications caused by DNS issues, poor wireless design, overloaded servers, and damaged cables.
The important part is not knowing the answer before you start. The important part is knowing where to look first.
Good network troubleshooting is less about guessing and more about eliminating possibilities in the right order.
Start by defining “slow”
“Slow network” is one of the least useful descriptions in IT. Slow doing what? Opening websites? Accessing a file server? Making a video call? Different problems point to completely different causes.
The first thing I do is narrow down the complaint. If only one application is slow, that tells me something very different than every device in the building being affected. A network issue that affects everything is a very different problem from one affecting one service or one user.
Separate the local network from the Internet
The ISP is usually the first suspect because it’s the easiest thing to blame. The Internet feels like one big service. The reality is that most network traffic never leaves the building.
A user opening a file from a local server, printing a document, or connecting to a local application has nothing to do with the ISP connection. One of the first questions I ask is whether the problem exists inside the network or only when reaching external services.
I’ve seen businesses upgrade their Internet package to solve problems caused by old switches and overloaded wireless networks. They paid more every month and nothing improved.
Wired versus wireless matters
Wireless problems often disguise themselves as general network problems. A laptop over Wi-Fi feels slow, so everyone assumes the network is slow. Then someone plugs in a desktop over Ethernet and everything works normally. Now the problem has a direction.
Wireless adds variables that wired networks don’t have: interference, channel congestion, poor coverage, roaming behaviour, and client decisions all affect performance. When troubleshooting, I always compare wired and wireless behaviour. The difference usually tells you more than another speed test.
Check the simple things before the complicated things
A surprising number of network problems come down to basic issues. A bad cable. A failing switch port. A device negotiating at the wrong speed. A port accumulating errors. A piece of hardware that’s been running continuously for eight years.
I’ve walked into environments where teams had spent days investigating software problems, only to discover a network interface was dropping thousands of packets. The network was telling them what was wrong. Nobody was looking.
Latency tells a story
When I investigate a slow network, I’m interested in how devices are communicating, not just whether they can communicate. A connection can be available and still be unhealthy.
High latency, packet loss, and inconsistent response times often point toward congestion, hardware problems, or overloaded links. A network that works perfectly at 9:00 AM but struggles every afternoon is giving you a clue. Something is changing—more users, more traffic, more backups, more wireless devices. The timing matters.
DNS gets blamed less than it should
DNS is one of those services people rarely think about until it breaks. When DNS is slow or unreliable, users often describe the entire Internet as slow. Websites take longer to open. Applications appear frozen. Cloud services feel unreliable.
The network connection itself may be perfectly healthy. DNS problems are frustrating because everything eventually works—it just takes longer than expected. That delay is often enough for users to assume the whole network is failing.
Avoid changing random settings
One of the worst troubleshooting habits I see is changing things until something appears to improve. Restart the router. Change a firewall setting. Replace a switch. Modify wireless channels.
Sometimes the problem disappears. Sometimes it returns later. Without understanding the cause, you’ve learned almost nothing. Good troubleshooting creates a clear connection between an observation and a change. If you can’t explain why a change should fix the problem, you probably shouldn’t make it yet.
Look for patterns, not just failures
The best troubleshooting information usually comes from the details people think are unimportant. Does it happen only in one area of the building? Only at certain times? Only with wireless users? Only when large files are being transferred?
Those patterns narrow the possibilities quickly. A network problem is rarely random. It just looks random when you don’t have enough information.
Fix the cause, not the complaint
The fastest way to troubleshoot a slow network is not to start replacing equipment. It’s to understand the path between the user and the thing they are trying to reach.
Start local. Identify whether the issue is wired or wireless. Separate internal services from Internet services. Look at the health of the infrastructure. Follow the evidence instead of the assumptions.
A good network engineer isn’t the person who guesses the right answer quickly. It’s the person who knows how to stop guessing.
Questions or corrections? info@mb-networks.ca