Slow video calls and sluggish apps are hard to pin down without data. Network performance monitoring means measuring latency, jitter, packet loss and throughput over time, then comparing them with what is normal for your network.
This guide is part of our wider coverage of network monitoring.
| Item | Value |
|---|---|
| Latency | Measured in milliseconds |
| Jitter (example VoIP target) | Below 30 ms |
| Packet loss that can hurt TCP apps | 1-2% |
| Bandwidth | Measured in Mbps |
| Active testing tools | iPerf, Netperf |
Figures come from a ManageEngine OpManager blog post, a vendor source. Thresholds can change and vary by application, so check the source before you rely on them.
What network performance monitoring measures
Performance monitoring is about how well the network carries traffic, not just whether a device is up. A switch can answer a ping and still deliver a poor experience to users.
The raw signals are called metrics. The source describes them as “latency in milliseconds, jitter, packet loss percentage, bandwidth in Mbps.” Each tells you something different about user experience.
Good monitoring collects these continuously, stores the history, and lets you see trends rather than single snapshots. A single reading says little; a week of readings shows a pattern.
The core metrics explained
Latency
Latency is the time a packet takes to travel across the network, often reported as round-trip time. High latency makes applications feel sluggish and unresponsive, even with plenty of bandwidth.
Do not stop at one final number. A spike between two specific hops in a traceroute can point to a congested router or a problem at an ISP peering point rather than a failing end device.
Jitter
Jitter is the variation in latency from one packet to the next. It matters most for voice and video, where packets must arrive at an even pace.
The source gives an example target: “VoIP call jitter must remain below 30ms”. Treat that as a starting point, not a standard, and watch for spikes as well as averages.
Packet loss
Packet loss is the share of packets that never arrive. The source warns that a seemingly tiny amount, “1-2%”, can cripple TCP-based applications.
Our guide to packet loss covers causes and diagnosis in more depth.
Throughput versus bandwidth
Bandwidth is the capacity of a link. Throughput is “the actual amount of data successfully transferred over that link in a given time.”
If enough traffic is offered to use the available bandwidth but throughput consistently lags far behind it, something may be wrong: congestion, errors, a misconfigured duplex setting or a limit elsewhere on the path.
How the data is collected
No single method sees everything. Most setups combine two approaches.
- Passive monitoring: SNMP polling and NetFlow observe real traffic and device counters such as interface errors, discards and utilisation.
- Active monitoring: tools such as iPerf and Netperf generate test traffic to measure bandwidth and latency on demand or on a schedule.
- Probes: regular ICMP pings graph round-trip delay and loss between chosen points.
SNMP is excellent for per-interface counters but is weak at measuring end-to-end delay or jitter by itself. That is why active tests are paired with it.
Why baselines beat fixed thresholds
Static thresholds, such as “CPU > 80%”, can cause alert fatigue, as the source notes. A link that normally runs hot at month end would alert constantly, while a quiet link could degrade badly without crossing any line.
A network baseline records what normal looks like for each link and time of day. Alerts then fire on meaningful deviations from that normal.
Build a baseline from several weeks of data that include your busiest periods. Re-check it after any major change, such as a new site, a new application or a carrier switch.
A practical monitoring routine
- List the applications that matter most, such as voice, video or a business system, and note what each needs.
- Choose the paths that carry them and monitor both ends and the links in between.
- Collect interface counters through SNMP, and prefer the most secure SNMP version your devices support.
- Add scheduled active probes for latency, jitter and loss.
- Record a baseline, then set alerts relative to it.
- When users complain, compare the current readings with the baseline and use traceroute to locate where delay appears.
Keep the set of metrics small at first. A few well-understood graphs are more useful than a sprawling wall of unread ones.
Reading the graphs when something goes wrong
Metrics are most useful when you read them together. One reading rarely explains a complaint, but a combination usually points to a cause.
- Latency up, loss steady: often congestion or a longer path after a routing change. Check interface utilisation and traceroute.
- Loss up with interface errors: look at cabling, optics, duplex mismatches or a failing port.
- Jitter up, average latency flat: bursty traffic competing with real-time flows, which queueing and prioritisation settings may need to address.
- Throughput low, utilisation low: the limit is probably elsewhere, such as the remote server, a firewall or the application itself.
Always note the time the problem started. Lining it up against change records, backups and scheduled jobs often explains it faster than any tool.
Setting alerts people will trust
An alert is only useful if someone acts on it. Too many false alarms train a team to ignore the system, so start with a few alerts tied to real user impact.
Require a condition to persist for a short period before firing, so one stray slow reply does not page anyone. Send different severities to different places: a chat message for a mild drift, a call for a sustained outage on a critical path.
Review alerts regularly. Remove the ones nobody acts on and tighten the ones that fired too late. Over time the rules should reflect how your network really behaves.
Where to place monitoring points
Where you measure from changes what you learn. A probe sitting in the data centre sees the data centre’s view, not the experience of a branch office on a slow link.
Place probes close to users and close to the services they depend on. Measuring from both sides of a suspect link lets you tell whether the delay is inside your network or beyond it.
For cloud and remote work, add probes at the edge and in each major region you use. Home and mobile connections are outside your control, but a probe on the path to your own gateway still shows whether the problem starts with you.
Document each monitoring point, what it tests and how often. When a new engineer joins, that list explains why a graph looks the way it does.
Common mistakes
- Watching only average values and missing short spikes.
- Treating rated link speed as real performance.
- Monitoring devices but not the user-facing path.
- Copying thresholds from a vendor blog without testing them against your own traffic.
Frequently asked questions
What is network performance monitoring?
Show answer
It is the continuous measurement of metrics such as latency, jitter, packet loss and throughput, so you can spot degradation before users do.
Is SNMP enough on its own?
Show answer
Usually not. SNMP gives device and interface counters, while active probes such as iPerf or Netperf measure delay and bandwidth along a path.
What jitter value is acceptable?
Show answer
It depends on the application. One vendor example uses below 30 ms for VoIP, but treat that as a starting point and tune it using your own baseline.
Why does throughput differ from bandwidth?
Show answer
Bandwidth is link capacity; throughput is what actually gets through. Congestion, errors and loss all widen the gap.
