What Are Network Performance Metrics? How to Track and Fix Issues (2026)

Network performance metrics are the diagnostic layer between your infrastructure and your users. They explain why things are slow, dropped, or unreachable by capturing everything from how fast packets travel and how much bandwidth is in use to how often data gets dropped or delayed. 

For IT teams, they’re the difference between knowing exactly where a problem is and spending hours guessing.

In this article, we cover the core metrics every IT team should track, including bandwidth, latency, throughput, packet loss, jitter, RTT, and availability. You’ll learn how each one works, how they influence one another, which one to check first based on user reports, and how to build a monitoring strategy around them.

What Are Network Performance Metrics?

Network performance metrics are quantitative and qualitative indicators used to measure, monitor, and evaluate the overall health, speed, and reliability of a computer network.

These network performance metrics fall into two types:

• Quantitative metrics are numbers you can measure directly, like latency in milliseconds, bandwidth in Mbps, or packet loss as a percentage. 
• Qualitative indicators are broader ideas, like “network stability” or “good user experience.” You can’t measure these directly. Instead, you work them out by looking at several quantitative metrics together.

For example, let’s say a network reports 50ms latency, 0% packet loss, and 200 Mbps throughput. These three numbers suggest the network is healthy. But the same network could still have 15ms of jitter, a number none of those three metrics would catch. 

That small amount of jitter alone can make a VoIP call sound choppy. This is why monitoring tools track several metrics simultaneously instead of relying on just one number.

Key Network Performance Metrics to Monitor

Track the following metrics: 

1. Bandwidth 

Bandwidth is the maximum amount of data a network or communication channel can handle in a given time. It’s usually measured in megabits per second (Mbps) or gigabits per second (Gbps).

Bandwidth and throughput are often confused, but they measure different aspects of network performance:

• Bandwidth is the maximum capacity available. 
• Throughput is the amount of data that actually moves through that capacity under real conditions, after accounting for network congestion, packet loss, and other overhead. 

A connection can have high bandwidth and still deliver low throughput if the network is busy or the hardware can’t keep up.

For example, a connection with 100 Mbps bandwidth might deliver only 60 Mbps of actual throughput during peak hours. The other 40 Mbps is lost to congestion and retransmissions. This is why both numbers matter. Bandwidth tells you the most you could ever get. Throughput tells you what you’re actually getting right now.

2. Latency and Round-Trip Time (RTT)

Latency is the time it takes for data to travel from its source to its destination, in one direction only. It’s measured in milliseconds (ms). 

Lower latency means a faster, more responsive connection. Higher latency causes noticeable delays, especially in real-time applications like video calls, online gaming, and financial trading.

Round-trip time (RTT) is the total time it takes for data to travel to a destination and then come back to the source. In simple terms, latency measures one direction. RTT measures the full round-trip.

This is important to understand because most monitoring tools actually report RTT, not one-way latency. 

Commands like ping send a packet and time how long it takes to get a response back, which means they measure RTT by design. 

True one-way latency is harder to measure because it needs precisely synchronized clocks on both ends of the connection. So when a dashboard shows you a “latency” number, it’s very often showing RTT.

For example, a video call with 75ms of latency in each direction has an RTT of about 150ms. The ITU-T G.114 standard, a widely used voice quality benchmark, recommends keeping one-way latency under 150ms for acceptable voice call quality. Past that point, users start to notice delays and talk over each other during calls.

High latency can come from a few causes: 

• physical distance between devices
• network congestion
• misconfigured routing protocols like BGP or OSPF. 

Monitoring latency and RTT across different parts of your network helps you find exactly where the delay is happening.

3. Throughput

Throughput is the actual amount of data that is transferred across a network in a given time, measured in Mbps or Gbps. It shows you what your network is delivering right now, not what it’s theoretically capable of delivering. 

Throughput is always lower than bandwidth. A 1 Gbps link has 1 Gbps of bandwidth but typically delivers 850 to 950 Mbps of throughput due to protocol overhead, retransmissions, and congestion. 

The gap between those two numbers is where most performance complaints come from.

Several things reduce throughput below available bandwidth: 

• network congestion
• packet loss that forces data to be resent
• TCP’s own congestion control mechanisms that deliberately slow down data transfer when it detects packet loss. 

This means two networks with the same bandwidth can deliver very different throughput depending on how much packet loss and congestion each one has.

For example, a file backup that should transfer 10GB in 10 minutes at full bandwidth might take 25 minutes if packet loss is pushing retransmissions up. The bandwidth is the same. The throughput is not.

You can measure throughput using NetFlow. For teams running SaaS-heavy environments, measure throughput from the user’s endpoint to the SaaS application edge, not just from your edge router. That is the path that directly affects what users experience.

4. Packet Loss, Error Rate, and Retransmission

These three metrics are related, and understanding how they connect helps you diagnose problems faster:  

a. Error rate measures how often transmission errors happen at the network interface level. A high error rate is an early warning sign that something is wrong, whether it is a faulty cable, failing hardware, or heavy congestion. It warns you there is a problem, but not exactly what kind.

b. Packet loss is more specific. It measures the percentage of data packets that are sent but never arrive at their destination. In most networks, a rate of less than 1% is generally considered acceptable and unlikely to noticeably affect performance. High packet loss is typically defined as anything above 5%, at which point users will likely experience noticeable delays and disruptions. 

c. Retransmission is what TCP does automatically when it detects packet loss. It resends the missing or damaged packets so the data eventually arrives complete. But it comes with a cost: retransmissions consume extra bandwidth on top of the original transfer. So high retransmission rates mean two things at once: 

• packet loss is happening
• the network is paying an additional bandwidth cost to recover from it. 

This is why packet loss compounds: it does not just slow down the affected transfer. It slows down everything sharing that network path.

For example, imagine a file transfer where 3% of packets are being lost. TCP retransmits the missing data, but each retransmission adds to the traffic on an already busy link, which can trigger even more congestion and more loss in a cycle that is difficult to break without addressing the root cause.

The root causes of packet loss follow a clear pattern: random loss usually points to temporary congestion, while consistent or systematic loss points to hardware failure, a faulty cable, or a persistent misconfiguration that needs to be fixed directly.

5. Jitter

Jitter is the variation in the time it takes for packets to arrive at their destination. In a healthy network, packets arrive at a steady, predictable pace. When jitter is high, some packets arrive early and some arrive late, causing gaps and out-of-order delivery that disrupt the flow of data.

Jitter only becomes a visible problem in real-time applications. For file downloads or email, the order and timing of packets does not matter much because the application reassembles everything before showing it to you. But for a live voice call or video conference, packets need to arrive in the right order at the right time. When they do not, the result is choppy audio, robotic-sounding voices, or frozen video frames.

The widely accepted threshold across the industry is clear: acceptable jitter for VoIP is anything below 30 milliseconds. When jitter stays under this threshold, call quality is clear. Once it exceeds 30ms, you will likely experience choppy audio, echoing, or delayed voice transmission. 

The most common causes of jitter are network congestion, inconsistent routing, and overloaded hardware. When a network path is congested, packets get queued and released at uneven intervals, which is what creates the variation in arrival times.

For example, if your team is on a video call and someone else on the same network starts a large file download, the sudden congestion can push jitter above 30ms within seconds. The call was fine before the download started because the link had room. The download consumed that room, and jitter spiked immediately.

6. Network Availability

Network availability is the percentage of time a network and its critical components are accessible and working for users. When availability drops, users cannot connect to the applications and services they depend on, regardless of how well other metrics like throughput or latency look.

The standard formula for calculating availability is:

Availability (%) = (Total Time – Downtime) / Total Time x 100

Most enterprise SLAs are built around a small set of availability targets that have become industry standard:

• 99.9% uptime (three nines) allows about 8 hours and 46 minutes of downtime per year
• 99.99% uptime (four nines) allows only 52 minutes and 35 seconds of downtime per year

One important thing to understand is the difference between a network being technically “up” and being functionally available to users. 

A network can show 100% uptime on a device status check while still being unusable if latency has spiked above tolerable levels or packet loss is high enough to break application connections. This is why availability should always be monitored alongside latency and packet loss, not as a standalone number.

For example, a VPN service can appear online to a monitoring tool while users on the other side of a congested WAN link cannot actually establish a session. The network is technically up. But it is not functionally available to the people who need it.

7. Application Response Time

Application response time is the total time between a user sending a request and the application delivering a complete response. It captures both network delay and the time the server takes to process the request, which makes it different from latency. 

Latency measures only network travel time. Application response time includes that plus server processing time, like running a database query or loading application logic.

For interactive applications such as e-commerce websites, SaaS dashboards, and mobile apps, response times under one second are generally acceptable. Once performance crosses the one-second threshold, users can notice delays. (source) 

This metric also provides valuable context for a key diagnostic question: Is the slowdown coming from the network or the application? If latency is stable but response times are climbing, the problem is likely on the server side. If both are rising together, the network is the more likely cause.

How Network Performance Metrics Relate to Each Other

Each network metric measures something different, but they do not behave independently. A change in one metric almost always affects others. 

Here are the key relationships to know:

Bandwidth does not guarantee throughput 

Bandwidth is the maximum your connection can carry. Throughput is what actually gets delivered after congestion, packet loss, and protocol overhead take their share. 

High bandwidth enables high throughput, but high latency or packet loss can reduce actual throughput well below available bandwidth. 

A 1 Gbps link with 3% packet loss will consistently deliver far less than 1 Gbps of real throughput.

Packet loss compresses throughput and raises latency at the same time

When TCP detects packet loss, it interprets it as a congestion signal and reduces its sending rate. Lost packets must also be retransmitted, which adds latency while the sender waits to detect the loss and resend. 

So packet loss does not just slow down the affected transfer. It actively shrinks the throughput available to every other connection sharing that path.

High latency degrades user experience even when throughput is adequate

A network can deliver 500 Mbps of throughput and still feel slow if latency is high. This is especially true for applications that send many small requests and wait for a response before sending the next one, such as web applications and database queries. 

Each round trip adds latency costs, and those costs add up quickly.

Jitter only becomes visible in real-time traffic

For file transfers or email, variation in packet arrival times does not matter because the application waits for everything before displaying it. 

For a voice call or video conference, packets must arrive in order and on time. 

Even 10ms of jitter that would be invisible in a file download can make a voice call sound choppy.

RTT is the best single proxy for what users feel

One-way latency tells you where the delay is happening. RTT tells you what users experience during an interactive session. 

Higher RTT means the sender waits longer before receiving acknowledgment, which reduces effective throughput and slows TCP connection growth during the early phase of a transfer. 

Here is a simple summary of how the metrics influence each other:

Which Network Metric Should You Check First?

When users report a problem, the behaviour they describe usually points to a specific set of metrics. 

Use this table as your first reference when a complaint comes in:

What Factors Affect Network Performance?

Network performance problems don’t always come from the same place. Some start inside your infrastructure, some from configuration decisions, some from how applications behave, and some from factors completely outside your network. 

1. Infrastructure Quality

The physical hardware your network runs on sets a hard limit on performance:

• Old routers and switches cannot keep up with modern traffic volumes. 
• Faulty cables can introduce transmission errors that appear as rising interface error rates, packet loss, and retransmissions.
• Outdated hardware limits throughput even when the network link itself has plenty of capacity.

Suppose a switch nearing the end of its life starts dropping packets under normal load. The symptom looks like congestion, but replacing the switch fixes it immediately. Regular hardware checks and timely replacements prevent this type of problem.

2. Configuration Choices

Wrong routing settings, poor QoS policies, and badly designed network segments all hurt performance without any hardware failure. A routing mistake can send traffic on a longer path than needed, adding latency to every request that uses that route.

For example, a BGP misconfiguration causes traffic between two offices to route through an external ISP instead of a direct WAN link. RTT doubles for all users on that path. The network is fully working. It is just configured wrong.

3. Traffic and Application Workload

Different applications put very different demands on a network: 

• File backups and video streaming consume a lot of sustained bandwidth. 
• VoIP and video conferencing are sensitive to even small amounts of latency, jitter, and packet loss. 
• ERP systems at month-end create sudden traffic spikes that push utilization past safe levels in short bursts.

If you know your workload mix, you can apply the right QoS policies and plan capacity correctly. 

4. Environmental and External Factors

These are often the hardest to find because they come from outside your direct control. Electromagnetic interference (EMI) from nearby devices can degrade wireless signals and introduce errors on cables. 

Physical barriers like walls reduce Wi-Fi signal strength. 

Nearby wireless networks on the same channel can interfere with your own wireless signals, creating problems that look like infrastructure failures. 

ISP issues are another common external factor. Bandwidth throttling, congested connections, and routing problems and pending issues inside your ISP’s network all affect WAN performance in ways you cannot fix internally. 

5. Security Overhead

Security tools use network resources as part of their normal operation. Deep packet inspection can slow down traffic in transit, and finding the right balance between security and performance requires careful tuning. 

Firewalls handling heavy traffic can become bottlenecks if they are not sized for that load. Malware on a compromised device can also consume a lot of bandwidth as it scans the network, creating congestion with no obvious cause. 

For example, turning on full SSL/TSL inspection on a firewall not built for it can cut throughput by 30 to 50% and raise latency noticeably, even though the network links have not changed at all.

Network Monitoring Protocols: How Metrics Are Collected

Network performance metrics are gathered by a specific protocol, and each protocol captures a different layer of network behavior. 

Here is what each protocol does and which metrics it feeds:

SNMP (Simple Network Management Protocol)

SNMP is the most widely used standard networking protocol for device monitoring. It polls network devices for metrics like CPU usage, memory load, and interface health. 

SNMPv3 adds encryption and authentication, making it more secure for environments that need real-time alerts without constant polling. 

SNMP is the right tool when you want to know what a device is doing. It does not tell you what traffic is flowing through it. 

NetFlow, sFlow, and jFlow

Where SNMP focuses on device status, NetFlow focuses on behavior. It captures flow data including source and destination IP addresses, ports, and protocols, which helps you understand how traffic moves through your network. 

That visibility is key for traffic management, capacity planning, and spotting abnormal patterns. 

sFlow and jFlow are vendor-specific variations that work the same way. But use NetFlow when you want to know who is using your bandwidth and how much.

ICMP (Internet Control Message Protocol)

ICMP is the network protocol behind ping and traceroute. It is the fastest way to check if a device is reachable and how long the round trip takes. It measures latency, RTT, and basic packet loss. 

ICMP does not give you traffic details or device health data, but it is the first tool most teams reach for when a connectivity problem is reported.

Syslog

Syslog is the standard network protocol used to send, store, and organize system logs. It collects event messages from network devices and sends them to a central log server. It captures configuration changes, login failures, and hardware errors. 

While SNMP offers quantitative metrics, syslog provides qualitative event data. Together they give a more complete view of network health, with SNMP suited for performance monitoring and syslog for event auditing. 

DPI (Deep Packet Inspection)

DPI inspects the actual content of packets, not just their headers. This lets it classify traffic by application, detect anomalies, and measure application-layer performance. 

It is more resource-intensive than SNMP or ICMP, so most teams use it for targeted troubleshooting rather than continuous monitoring across the whole network.

API Endpoints

Modern cloud services and SaaS applications expose performance data through APIs. Monitoring API endpoints lets you track application availability and response time for services that do not support traditional protocols like SNMP. 

This is especially important in hybrid environments where part of your infrastructure runs in the cloud and part runs on-premises.

AI-Powered Monitoring

SNMP, NetFlow, ICMP, Syslog, DPI, and API endpoints all collect raw data. AI and machine learning platforms take that raw data and help you make faster, smarter decisions with it.

The main difference from traditional monitoring is how thresholds work. 

Traditional tools require you to manually set alert thresholds for each metric. AI-powered platforms learn what normal looks like on your network and flag anything that does not match, even when the metric has not crossed a fixed threshold. 

Three specific things make AI monitoring useful for network performance metrics:

• Automated baselining: Instead of manually deciding what “normal” looks like for latency or throughput, the platform builds baselines from your actual traffic patterns across different times of day, days of the week, and application types.
• Anomaly scoring: When a metric behaves unusually, the platform scores how significant the change is, so your team focuses on real problems instead of noise.
• Predictive capacity planning: By tracking trends in bandwidth utilization and throughput over time, AI tools can flag links or devices that are filling up weeks before users notice any slowdown.

Building a Network Monitoring Strategy

Here’s how to build a network monitoring strategy around what actually matters to your business. 

Here’s the reworked section with each subheading as a direct instruction:

Set your thresholds based on your SLAs

Pull up your SLAs and use them to define every threshold you set. For each metric, ask: what level of performance does the business actually require? That number is your threshold.

Be specific. “Keep latency low” is not a useful target. “Keep one-way latency below 100ms for VoIP traffic during business hours” is. 

Once you have that number, set your alert at 80 to 90% of it so you get notified before the breach, not after. If your SLA requires packet loss below 1%, your alert fires at 0.7%.

Collect two to four weeks of data before you set any threshold

Don’t set thresholds on day one. Run your monitoring tools for at least two to four weeks first and let them collect real traffic data across different times of day and days of the week. Then set your thresholds based on what you actually see, not what a default value suggests.

Default values like 80% CPU are too sensitive for most environments and will generate noise. Once you have your baseline, 90% or 95% is usually the right ceiling; high enough to avoid false alerts, low enough to catch real problems before users feel them.

Apply QoS rules to protect your highest-priority traffic

Identify your most latency-sensitive applications such as VoIP, video conferencing, or anything real-time, and assign them appropriate QoS rules that give them priority over everything else. 

File backups, software updates, and bulk transfers should wait. Real-time traffic should not.

Do this before problems appear. 

If jitter is already above 30ms during business hours, add a QoS rule prioritizing voice packets over bulk transfers and recheck your jitter and packet loss numbers. If they drop, the rule works. If they don’t, the problem is elsewhere.

Track trends weekly

Set aside time each week to look at how your key metrics are trending. A WAN link at 60% utilization with no alerts is fine today but if it’s growing 5% per month, you have eight months before it begins affecting application performance or requires a capacity upgrade. 

If you catch that trend now, it means you plan a capacity upgrade. But if you miss it, you would have to scramble during an incident.

Bring every environment into one monitoring view

If you’re monitoring on-premises devices in one tool, cloud traffic in another, and SaaS performance in a third, you will miss the connections between them when something degrades. 

Consolidate into a single platform that correlates SNMP data from devices, NetFlow data from traffic, and API data from cloud services together. 

Root cause analysis on a cross-layer issue is only possible when you can see all the layers at once.

Use Edwin AI to automate what manual monitoring can’t keep up with

Once your strategy is in place, Edwin AI handles the parts that manual monitoring can’t scale to such as: 

• Building baselines from your actual traffic patterns
• Scoring anomalies so your team focuses only on what’s genuinely abnormal
• Flagging capacity issues weeks before users notice them

Every action follows the policies and limits you define, so nothing happens automatically without your approval. As a result, your team spends less time managing thresholds and more time resolving network issues.

How LogicMonitor Helps You Monitor Network Metrics

Network performance metrics only create value when they’re connected to the services that depend on them, and to the actions your team needs to take. 

That’s the gap most monitoring tools leave open. But LogicMonitor closes it.

LogicMonitor is the AI-first platform for Autonomous IT, built to help enterprises move from reactive operations to a governed operating model where issues are detected, understood, and resolved — often before users ever feel them. 

The platform connects three components that work together as one system:

LM Envision provides the telemetry foundation, unified hybrid observability across infrastructure, cloud, and edge. Every network metric covered in this article flows through LM Envision, giving your team a single source of truth across on-premises devices, cloud environments, and hybrid paths.

Catchpoint extends that visibility beyond your internal systems into the full delivery environment your users actually depend on: Internet paths, external dependencies, DNS, ISPs, and digital experience. When a network performance issue originates outside your infrastructure, Catchpoint is what lets you see it.

Edwin AI uses specialized AI agents and turns that shared signal into governed action. Embedded across the platform, Edwin learns what normal looks like across your specific environment, flags deviations before they cross SLA thresholds, and helps your team move from data to decision faster. It doesn’t act without oversight; every action happens within defined guardrails, with approvals, audit trails, and validation built in.

Together, the three components support a closed loop: detect signals across the full environment, understand service impact, reason and prioritize, decide the next action, act within guardrails, and verify the outcome.

Here’s how that maps to the network monitoring metrics:

Edwin AI eliminates the manual threshold-setting that most monitoring approaches require. Instead of guessing what “normal” looks like for your environment, Edwin builds baselines from your actual traffic patterns, across times of day, days of the week, and application types, and surfaces anomalies before they become incidents.

FAQs

By Dennis Milholm

Sales Engineer, LogicMonitor

Subject matter expert in IT and Managed Services with 20+ years of experience across NOC operations, product management, and service delivery.

Disclaimer: The views expressed on this blog are those of the author and do not necessarily reflect the views of LogicMonitor or its affiliates.

© LogicMonitor 2026 | All rights reserved. | All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.