The network is slow.
Nothing is busy.
If you are here, you have probably already checked the obvious thing: no link is saturated, no device is at its limit, and every graph is green. That rules out the easy answer and leaves the hard one. Here is what is usually actually happening.
Why your monitoring has nothing to say
Almost every monitoring platform works from device counters — how many bytes crossed an interface, how many packets, how full the link is. Those counters are excellent at answering one question: is this link busy?
When the answer is no, the tool has run out of things to tell you. It cannot seehow the traffic behaved — whether sessions were retransmitting, whether handshakes were failing, whether the delay came from the network or from something at the far end. That information only exists in the packets themselves, and counters throw the packets away.
Which is why "the network is slow but everything looks fine" is the single most expensive sentence in network operations. Everything does look fine. You are looking at the wrong layer.
Six causes of a slow network that is not busy.
In rough order of how often we find them. Each one is invisible on a utilisation graph.
Duplex mismatch on a single port
01One side of a link negotiated full duplex, the other half. Throughput looks unremarkable because the traffic is not heavy — but collisions and retransmissions make every session on that path feel dreadful.
Tell-tale sign — Rising error and retransmission counters on one interface while utilisation stays low.
TCP retransmission and packet loss
02A small percentage of packets being lost forces TCP to back off and resend. A 2% loss rate is almost invisible on a bandwidth graph and can cut effective throughput by an order of magnitude.
Tell-tale sign — Applications feel slow in bursts. Large transfers crawl while small requests seem fine.
Latency, not capacity
03Chatty applications that make hundreds of round trips per operation are punished by latency, not bandwidth. Adding a bigger link changes nothing at all, because the link was never the constraint.
Tell-tale sign — A remote site is slow while its WAN circuit sits at a third of capacity.
DNS and authentication delays
04The network is fine and the wait is elsewhere — a slow DNS resolver, an overloaded domain controller, a certificate check timing out. Users experience it as "the network", and the network team gets the ticket.
Tell-tale sign — Everything is slow to start but fast once it is running.
Micro-bursts
05Traffic that saturates a link for milliseconds at a time, filling buffers and dropping packets. Five-minute average graphs smooth this away completely, so the interface reports a comfortable 30% while it is intermittently overwhelmed.
Tell-tale sign — Intermittent slowness that never correlates with anything on the utilisation chart.
A change nobody logged
06A QoS policy, an ACL, an MTU value or a routing preference altered on one device. Nothing alarms, because from the monitoring system nothing is wrong — it is just quietly worse than it was yesterday.
Tell-tale sign — It started at a specific time and nobody can say what happened then.
The two stories, on one timeline.
Drag it. Utilisation holds flat and comfortable for the entire incident — it never once approaches its alert limit — while response time climbs from 24 ms to nearly half a second. Both lines are the same network at the same moment.
Net-Monitor has learned what this part of your network normally does at this time of day. Traffic is comfortable, the wire is clean, and nobody needs to be told anything.
- Link utilisation
- 39%
- Response time
- 24ms
- Sniffer packet errors
- 0.2%
- Risk score
- 2/100
Utilisation is comfortable and the wire is clean.
You have to look at the traffic, not the totals.
Every cause above leaves evidence in the packets and almost none of it in the counters. That is the whole reason Net-Monitor reads all three layers rather than stopping at the first.
Every router, switch and server checked continuously — availability, response time, port status and errors, across every vendor you own.
Turns a link into names: which users, which applications, which servers are talking to each other, and how that pattern changes.
The sniffer records the packets themselves. Delay, retransmission, failed handshakes, sessions falling over — the things that make a network feel broken while every counter reads normal.
All three answers together, checked against what normal looks like for you — so you get the problem and the cause, not just a red icon.
And when it already happened
The worst version of this problem is the intermittent one — it is slow for ninety seconds, and by the time anyone logs in to look, it is gone. Net-Monitor's sniffer records continuously and keeps what it records, so you can go back to the exact minute it happened and see what was really on the wire, days or weeks later.
Short answers.
Why is my network slow when utilisation is low?
Because bandwidth is only one of the things that can make a network feel slow. Retransmission, packet loss, latency on chatty applications, DNS delays and micro-bursts all degrade the experience badly while leaving utilisation graphs completely flat. Utilisation answers "is this link busy?" — it cannot answer "why is this slow?"
Can a network be slow without high bandwidth usage?
Yes, and it is the most common case in a well-provisioned network. A 2% packet loss rate is invisible on a bandwidth graph and can cut effective throughput by an order of magnitude, because TCP backs off and resends. Adding more bandwidth changes nothing, because bandwidth was never the constraint.
Why does my monitoring show everything is fine?
Most monitoring platforms read device counters — bytes and packets per interface. When those look normal the tool has nothing left to report. The evidence for the real cause exists only in the traffic itself, and counters discard the traffic after counting it.
How do I find the cause of intermittent network slowness?
You need traffic that was recorded while it was happening. Intermittent faults are usually gone before anyone can start a capture, so the practical answer is continuous recording — a sniffer that is already running, so you can return to the exact minute afterwards and look at what was actually on the wire.
Still cannot explain it?
Bring us the network that is slow for no reason anyone can find. We will point Net-Monitor at it and show you what it sees — that is usually a short conversation.