Not sure which network monitoring metrics deserve a dashboard? Start with availability, latency, jitter, packet loss, throughput, utilization and interface errors, then baseline each one.
This guide is part of our wider series on network monitoring.
| Metric | What it tells you |
|---|---|
| Latency | Time it takes for data to travel across the network |
| Packet loss | Percentage of data packets that fail to reach their intended destination |
| Jitter | Variation in latency over time |
| Interface errors | CRC errors, discards and queue drops on a port |
| SNMP use | Interface utilization, error counters, CPU and memory |
These definitions come from ManageEngine’s checklist and Kentik’s guide. Vendor guidance can change, so check the sources before you rely on them.
The core set of network monitoring metrics
Kentik lists the key metrics as latency (RTT), packet loss, jitter, throughput, bandwidth utilization, errors, and application-layer signals such as DNS and HTTP response time. That is a good working list for most networks, from a single office to a multi-site WAN.
A useful way to read the list is by question. Each metric answers something different, and a dashboard that mixes them without labels tends to confuse more than it helps.
- Availability: is the device or link up at all?
- Latency: how long does traffic take to cross the network?
- Jitter and packet loss: how steady and complete is delivery?
- Utilization and throughput: how much of a link is in use, and how much data is moving?
- Errors: are there faults at the interface or protocol level?
- Application signals: do DNS and HTTP responses look healthy to the user?
None of these tells the whole story alone. A link can show low utilization and still drop packets because of a bad cable, and a path can have fine average latency while jitter ruins a video call.
Latency, jitter and packet loss
Kentik describes latency as a measure of network delays from the perspective of network devices such as clients, servers and applications. ManageEngine puts it more simply: latency is the time it takes for data to travel across the network.
Packet loss and jitter are the two metrics that sit closest to it. Kentik defines packet loss as the percentage of data packets that fail to reach their intended destination, and jitter as the inconsistency of packet arrival intervals, or the variation in latency over time.
ManageEngine says these two “go hand in hand with latency and directly affect call quality, video performance, and real-time applications.” That is why a file transfer can feel fine on a link where a voice call stutters: bulk transfers tolerate delay variation, while real-time audio does not.
Thresholds for all three are usually tied to service-level agreements. ManageEngine notes that VoIP often has strict limits for latency, jitter and packet loss, so those limits are a sensible starting point if you carry voice.
Utilization, throughput and interface errors
Kentik defines throughput as how much information is being or has been transferred. Utilization relates that traffic to the capacity of the link, which is what tells you whether you are close to a ceiling.
ManageEngine advises monitoring utilization at both the interface and flow level to identify whether spikes are tied to specific applications, users or events. The interface view tells you that a link is busy, and the flow view tells you why. For a deeper look at that side, see our guide to bandwidth monitoring.
Errors deserve their own panel because not all issues stem from bandwidth or congestion. ManageEngine says interface-level problems like CRC errors, discards or queue drops can signal failing cables, bad optics or misconfigured duplex settings. Kentik’s wider definition of errors includes bit errors, TCP retransmissions and out-of-order packets.
Where each metric comes from
Different metrics need different collection methods. Kentik names the core data sources as SNMP and streaming telemetry, flow telemetry (NetFlow/IPFIX/sFlow), cloud flow logs, synthetic monitoring, and optionally packet capture or host agents.
- SNMP polling for interface utilization, error counters, CPU and memory, as ManageEngine recommends.
- Flow data to see which applications and users drive the traffic.
- Synthetic tests for latency, jitter, loss and response time from the user’s point of view.
Kentik contrasts active, synthetic testing with passive forms of monitoring such as packet or flow data collection. In practice you want both: passive data shows what real traffic is doing, and active tests keep working when the network is quiet.
Polling frequency is a trade-off. ManageEngine recommends you double-check polling intervals so you don’t miss short spikes, because a counter read too rarely can hide a burst that users felt.
Turning metrics into a useful dashboard
A long list of charts is not a monitoring plan. Group the metrics by the decision they support, so that each panel answers a question someone actually asks.
ManageEngine’s checklist suggests a capacity and error summary view that lists the interfaces with the highest utilization, retransmissions, queue drops, CRC errors and discards, plus busy-hour trends. It also suggests weekly reviews that compare latency, loss and jitter trends week over week by site, path and time, to flag congestion or errors.
- Live view: availability, latency, jitter, packet loss, utilization and errors on priority paths.
- Capacity view: the busiest interfaces and busy-hour trends.
- Review view: week-over-week trends by site, path and time.
Keep the live view small. If everything is on screen, nothing stands out, and the metrics that matter most to your users, such as voice paths, get lost among the rest.
Baselines and alerting
Set a baseline before you set an alert. ManageEngine says a baseline per path and per application gives a clear picture of what “normal” looks like, and it recommends baselining availability, interface utilization, latency, jitter, packet loss and throughput.
A baseline keeps alerts honest. A branch office on a long WAN path will never match the latency of two servers in one rack, so a single global threshold either floods you with false alarms or misses real trouble.
A practical order of work looks like this:
- Discover your devices, links and priority paths.
- Collect the core metrics for a representative period.
- Set thresholds relative to each path’s normal behavior, tightening them for voice and video.
- Review trends regularly and adjust.
ManageEngine also suggests correlating alerts across layers, such as loss and jitter plus interface errors plus path changes, to reduce noise. When an alert does fire, a clean metric history makes network troubleshooting much faster, because you can see what changed and when.
Frequently asked questions
Which metric should I monitor first?
Show answer
Start with availability and interface utilization, then add latency, jitter and packet loss on your most important paths.
What is the difference between jitter and latency?
Show answer
Latency is the time data takes to cross the network. Jitter is the variation in that latency over time, which is why it hurts voice and video more than file transfers.
Can SNMP measure latency and jitter?
Show answer
SNMP suits interface utilization, error counters, CPU and memory. Latency and jitter generally come from synthetic tests rather than device counters.
Why do I need a baseline?
Show answer
A baseline shows what normal looks like for each path and application, so your thresholds reflect your own network rather than a generic number.
