“The network is slow.”
There it is.
The sentence that has launched a thousand unnecessary packet captures.
No application name. No source IP. No destination. No timestamp. No screenshot. No clue whether “slow” means a webpage took four seconds to load, Teams audio sounds like a robot drowning underwater, or someone’s Excel file took longer than usual to open.
Just:
The network is slow.
Unfortunately, “slow” is not a metric.
It’s an emotion.
And before we start blaming switches, routers, firewalls, ISPs, DNS, or whatever poor access point happens to be mounted closest to the person complaining, we need to figure out what kind of problem we’re actually dealing with.
Because latency, packet loss, jitter, congestion, and application delay are not the same thing.
They just all happen to wear the same cheap Halloween costume.
Meet the Usual Suspects
When users say something is “slow,” there are a handful of usual suspects.
Knowing which one you’re dealing with dramatically changes what you should investigate next.
Latency
Latency is how long it takes traffic to get from one place to another.
For most troubleshooting, we’re looking at round-trip time:
Client → Destination → Client
Measured in milliseconds.
Low latency is generally good.
Higher latency is not automatically bad.
A server sitting five feet away in the same data center should probably respond faster than something halfway across the planet.
Physics remains annoyingly undefeated.
A 50 ms connection across a WAN may be perfectly reasonable.
A 50 ms connection between two servers sitting in the same VLAN?
Now we have questions.
The important thing is context.
Latency Can Hurt More Than You Think
Applications also react differently to latency.
Imagine an application needs to make one request to a server.
Each round trip takes 50 ms.
No big deal.
Now imagine the application makes 40 sequential requests before displaying the page.
Suddenly:
50 ms × 40 = 2 seconds.
The network didn’t suddenly become terrible.
The application just decided to commute to work forty times before sitting down at its desk.
This is why application architecture matters so much when troubleshooting perceived network performance.
A perfectly acceptable amount of latency can become painful when an application is excessively chatty.
Packet Loss
Packet loss means traffic was sent but never successfully reached its destination.
That sounds bad.
And sometimes it absolutely is.
But this is also where troubleshooting gets messy.
Seeing one dropped ping does not mean:
THE NETWORK IS DROPPING PACKETS.
ICMP traffic may be deprioritized.
Devices may rate-limit ping responses.
Firewalls may treat ICMP differently than production application traffic.
And routers generally have more important things to do than immediately answer every engineer poking them with ping.
What matters much more is consistent end-to-end loss.
If you’re seeing sustained packet loss all the way to the destination, that’s interesting.
If one router occasionally ignores your ping while everything behind it responds perfectly?
That router probably isn’t guilty.
We’ll get much deeper into that in Part 2.
Packet Loss Can Look Like “Slow”
Packet loss doesn’t always produce an obvious outage.
TCP is designed to recover.
If packets disappear, TCP can retransmit them.
Which is great.
Except retransmissions take time.
So instead of the connection completely failing, users may experience:
Slow downloads
Pages that pause while loading
Applications that randomly hesitate
Sessions that feel inconsistent
File transfers that take much longer than expected
The network may technically still be working.
It’s just working like someone carrying groceries up three flights of stairs one bag at a time.
Jitter
Jitter is variation in latency.
And averages can hide it beautifully.
Imagine this:
20 ms
21 ms
19 ms
22 ms
18 ms
Pretty healthy.
Now this:
10 ms
12 ms
150 ms
14 ms
200 ms
The average might still look somewhat reasonable depending on the sample.
The user experience absolutely will not.
Jitter matters especially for real-time traffic like:
Voice
Video
Teams
Zoom
VoIP
Interactive remote sessions
A file transfer can usually tolerate packets arriving unevenly.
A conversation cannot.
Nobody wants their conference call arriving in installments.
Congestion
Congestion happens when more traffic is trying to move through a network resource than it can comfortably handle.
Think WAN circuits, Internet connections, overloaded links, or heavily utilized interfaces.
But here’s an important distinction:
High utilization does not automatically equal congestion.
An interface sitting at 85% utilization isn’t necessarily having a problem.
You need more evidence.
Things become more interesting when you see:
Queueing
Interface drops
Output drops
Increased latency
Packet loss
QoS queue drops
Performance degradation during high utilization
Utilization is evidence.
It is not a conviction.
The Time Dimension
Another important question:
When is it slow?
Because this:
“It’s always slow.”
is very different from:
“Every weekday between 9:00 and 10:00.”
The second one is practically begging you to investigate capacity.
Maybe backups are running.
Maybe a scheduled file transfer starts.
Maybe everyone arrives at the office and immediately opens seventeen cloud applications.
Maybe someone scheduled a replication job during peak business hours because calendars apparently weren’t invented yet.
Patterns matter.
That means timestamps matter too.
If the problem happened at 10:15 AM and you run a ping test at 3:45 PM, you’re not necessarily testing the same conditions.
A clean test several hours later proves very little.
Then There’s the Haunted Shed
Sometimes none of those things are the problem.
Sometimes the application is just built like a haunted shed.
Everything technically works.
But every door opens into another smaller, worse door.
You click a button.
The application:
Performs a DNS lookup.
Contacts an authentication service.
Calls an API.
Waits for a database query.
Calls another API.
Checks authorization.
Reads something from storage.
Calls another database.
Questions its life choices.
Finally loads your page.
The user waits six seconds.
And then someone opens a ticket:
Network latency issue.
Meanwhile:
Network latency: 12 ms.
Packet loss: 0%.
Interface utilization: normal.
Application response time: terrible.
At some point, you have to consider the possibility that the network is simply the road connecting two buildings that hate each other.
One Application vs. Everything
This is one of the fastest ways to narrow the problem.
Ask:
Is everything slow, or is one thing slow?
If users say:
Internet is slow
File shares are slow
Teams is slow
Internal apps are slow
Everything is terrible
Then yes, a broader network problem becomes more plausible.
But if:
Teams works
Internet works
File transfers work
DNS resolves immediately
Other internal applications work
…and one web application takes eight seconds to load?
I’m not saying it isn’t the network.
I’m saying the application team may want to keep their shoes on.
We’re coming over.
One User vs. Everyone
Same principle.
If one person says:
“The network is unusable.”
and 300 other users are happily working…
the WAN probably did not selectively declare war on Karen’s laptop.
Start smaller.
Look at:
The client
Wi-Fi
Ethernet
Docking station
VPN
Browser
Local CPU/memory
Endpoint security
DNS configuration
Driver issues
Scope tells you where to look.
One Site vs. Every Site
If every office is having the same problem, investigate shared infrastructure.
If only one office is having the problem, start looking at what’s unique to that site.
WAN circuit.
Local firewall.
Local ISP.
Switching.
Wireless.
Routing.
Maybe somebody unplugged something so they could charge a phone.
Never rule that one out.
Wired vs. Wireless
This one is especially useful.
If wired users work perfectly while wireless users struggle, congratulations:
You have just reduced your search area considerably.
If both wired and wireless users have the same problem, the issue may be further upstream.
This is what good troubleshooting looks like.
Not immediately finding the answer.
Eliminating things that aren’t the answer.
Internal vs. External
Another simple comparison:
Does the problem affect:
Internal resources?
Internet resources?
Both?
If internal resources perform normally but Internet services struggle, start looking toward:
WAN/Internet connectivity
ISP
Edge firewall
Internet routing
DNS resolvers
Proxy/SASE/security services
If both are affected, your scope changes again.
Every comparison eliminates suspects.
“What Changed?”
Yes.
That question.
The one everyone asks.
And everyone answers with:
“Nothing.”
Which usually means:
“Nothing that I know about.”
Check anyway.
Changes might include:
Firewall policy
Routing
QoS
VPN configuration
Application deployment
DNS
Load balancer configuration
Server patches
Cloud security policy
Endpoint security software
ISP maintenance
Network code deployment
“No changes” is not evidence.
It’s a starting assumption waiting to be betrayed.
Before You Blame the Network
When somebody reports “slowness,” start here:
Is it one user or many?
One application or everything?
One location or multiple locations?
Wired, wireless, or both?
Internal, Internet, or both?
Constant or intermittent?
When did it happen?
How long did it last?
What changed?
Is there measurable latency?
Is there actual end-to-end packet loss?
Does the issue follow a predictable pattern?
Don’t start with:
Which switch is broken?
Start with:
What exactly is happening?
That’s the difference between troubleshooting and randomly interrogating infrastructure until something confesses.
Related Config Chaos
The Blame Funnel: How to Troubleshoot Without Randomly Pinging Things
Start with a Layer 1–7 troubleshooting workflow before randomly interrogating infrastructure.
DNS: The Gaslighting Layer
Because sometimes “the network is slow” is really DNS doing exactly what someone told it to do three years ago.
Packet Crimes: Hunting Down the Jerk Flooding Your Network
When “slow” really does turn out to be something chewing through bandwidth, this is where the detective work starts.
How to Actually Bust Packet Crimes
A practical packet-capture guide for tracking down broadcast storms, noisy devices, and other network nonsense.
🔒 Paid: The “What Kind of Slow Is This?” Triage Guide
The fastest way to troubleshoot “slowness” is to stop treating every performance complaint as the same problem.
Here’s a repeatable triage process you can use when the ticket says nothing more useful than:
“Application slow. Please investigate network.”