Troubleshooting Network Latency: Complete Step-by-Step Guide

13 min

When a video call freezes mid-sentence, a cloud application times out, or a VoIP call turns choppy, the culprit is almost always the same: network latency. And while latency is impossible to eliminate entirely, the difference between a network that performs well and one that constantly frustrates users usually comes down to whether someone is actively troubleshooting network latency or just hoping it sorts itself out.

For network administrators, IT managers, and MSPs managing distributed infrastructure, high latency is not just a user experience problem. It affects productivity, SLA compliance, revenue-generating applications, and the trust clients place in your team. The challenge is that latency can originate from dozens of different sources, and chasing the wrong one wastes time and extends outages.

This guide walks through a systematic approach to troubleshooting network latency: what causes it, how to measure it, how to diagnose root causes, and how to fix the specific conditions driving delays in your environment.

---

---

What Is Network Latency (Quick Recap)

Network latency is the time it takes for a data packet to travel from its source to its destination. It is measured in milliseconds (ms), and lower is always better.

The most common framing is Round Trip Time (RTT), which measures how long a packet takes to travel to a destination and return. RTT is double the one-way latency and is the figure most diagnostic tools report. A useful reference from Wikipedia’s round-trip delay documentation notes that RTT varies significantly depending on distance, routing path, and infrastructure quality.

As a practical benchmark, most enterprise networks target an average latency of around 100ms or below. Applications with real-time requirements, such as VoIP or online gaming, often require 50ms or lower to function without noticeable degradation. When latency climbs above these thresholds consistently, something in the network path needs investigation.

---

The 6 Common Causes of High Network Latency

Troubleshooting network latency starts with understanding the range of possible root causes. High latency is rarely the result of a single universal problem. These are the six most common sources.

1. Long Physical Distance

Data travels at roughly two-thirds the speed of light through fiber. When a user in California is connecting to a server in Frankfurt, physics sets a baseline delay before any infrastructure issues even factor in. Geographic separation is often unavoidable, but it can be managed with CDN deployments and optimized routing.

2. Hardware Faults or Overloaded Devices

A router running at high CPU utilization, a switch with degraded memory, or a network interface card producing excessive errors will introduce measurable latency into every packet it handles. Faulty cables, bad SFP modules, and failing NICs create intermittent high-latency events that are notoriously difficult to trace without device-level visibility.

3. Network Congestion

When demand exceeds available bandwidth, queues build up and packets wait. This happens on WAN links during business hours, on wireless networks during peak usage, and on underpowered uplinks between network segments. Congestion-driven latency is often predictable and time-correlated.

4. Seasonal or Event-Based Traffic Spikes

A retail network during a product launch, a healthcare network at the start of open enrollment, or any environment hosting a large video conference can experience sudden, severe congestion. These are legitimate causes of high latency that require capacity planning rather than infrastructure fixes.

5. Lack of a Content Delivery Network (CDN)

When content is served exclusively from an origin server, every user who is geographically distant from that server experiences propagation delay. A content delivery network addresses this by caching content at edge locations closer to end users, reducing the round-trip path.

6. Suboptimal Routing or Configuration Issues

MTU mismatches, duplex mismatches, suboptimal BGP routing, and misconfigured QoS policies can all create latency without any hardware failure being present. These are configuration problems, and they often persist for a long time because they do not generate obvious error events.

---

Understanding Latency Components

Total network latency is the sum of four distinct delay types. Understanding which component is elevated helps narrow the troubleshooting scope significantly.

The standard latency formula is: Propagation Delay + Transmission Delay + Processing Delay + Queueing Delay = Total Latency

• Propagation Delay is the time for a signal to physically travel across the medium between two endpoints. This is determined almost entirely by distance and cannot be changed without physically relocating infrastructure or using CDN.
• Transmission Delay is the time required to push all bits of a packet onto the network link. It is affected by link speed and packet size. On high-speed links it is negligible, but on slow WAN connections or when large packets are queued, it adds up.
• Processing Delay is the time a network device (router, switch, firewall) takes to examine the packet header and determine where to forward it. On underperforming or overloaded hardware, processing delay increases noticeably.
• Queueing Delay is the time a packet waits in a buffer before it can be transmitted. This is the most variable component and the one most directly associated with congestion. High queueing delay is also the hallmark of bufferbloat, a condition where excessive buffer sizes create persistent high latency under load.

When you can identify which delay type is elevated, you dramatically shorten the list of possible causes. Propagation delay points to geographic or routing issues. Queueing delay points to congestion or misconfigured buffers. Processing delay points to hardware health or overloaded devices.

---

Step-by-Step Troubleshooting Process for Network Latency

A systematic approach prevents the common mistake of jumping to solutions before confirming root causes. These six steps provide a structured troubleshooting methodology for network latency issues.

Step 1: Perform Basic Checks

Before touching network infrastructure, eliminate the obvious. Verify whether the issue is isolated to a specific device or user, and whether it affects all applications or just specific ones. Check the affected device for high CPU or memory usage, background processes consuming bandwidth, and poor Wi-Fi signal. Confirm physical connections are seated properly and that the local modem and router have been rebooted recently. Many latency complaints are resolved at this stage without any deeper investigation.

Step 2: Measure Latency and Packet Loss

Once basic checks are complete, establish baseline measurements. Run a ping to a known reliable destination to check RTT and packet loss percentage. A clean connection should show consistent RTT values with zero packet loss. Varying RTT values suggest congestion or routing instability. Any packet loss is a signal that warrants deeper investigation.

Next, run a traceroute (or tracert on Windows) to map the hop-by-hop path from source to destination and identify where latency is being added. Each hop in the output shows the RTT for that segment. A sudden jump in latency at a specific hop indicates that segment is where the problem lives.

Step 3: Analyze the Network Path in Detail

Ping and traceroute give you a starting point. For a more complete view, use a network path analysis tool that sends continuous test packets and aggregates per-hop statistics over time, making it easier to identify intermittent issues that a single traceroute snapshot would miss. Look for consistent high RTT at specific hops, packet loss at specific segments, or route instability where the path changes between tests.

Domotz includes Route Analysis built directly into the platform. Based on MTR (which combines ping and traceroute functionality), it lets you send test packets to any public internet server, measure hop-by-hop packet loss and round-trip delay, and identify exactly where bottlenecks reside. You can specify packet counts of 10, 20, or 50 and run analysis on demand from the Collector Dashboard without needing separate CLI access or standalone tools.

Step 4: Correlate Performance Metrics

Latency does not exist in isolation. Compare your latency readings against throughput utilization, packet loss rate, and jitter measurements. If latency spikes align precisely with periods of high bandwidth utilization, the cause is congestion. If latency is elevated without any bandwidth pressure, examine device CPU and memory utilization, which may indicate a processing or hardware issue.

Domotz’s Network Troubleshooting feature aggregates latency, jitter, packet loss, and bufferbloat data in a single view across all monitored sites, making metric correlation significantly faster than switching between standalone tools.

Step 5: Check Device Health and Configurations

If path analysis points to a specific device as the source of delay, examine that device directly. Review CPU and memory utilization, interface error counters, and hardware health indicators. Look for duplex mismatches on Ethernet interfaces, which cause collisions and retransmissions that show up as intermittent latency. Check MTU settings across the path, as mismatched MTU values force packet fragmentation and add processing overhead. Review QoS configurations to confirm that latency-sensitive traffic is being prioritized correctly. Also check for outdated firmware that may have known performance issues.

Step 6: Monitor Bandwidth and Traffic Trends

If the problem appears to be congestion-driven, you need visibility into what is consuming your bandwidth. Use flow analysis data from NetFlow or sFlow to identify top talkers, unexpected traffic patterns, and bandwidth spikes correlated to specific times or applications. This data helps you determine whether the fix is a capacity upgrade, a QoS policy change, a traffic shaping rule, or removal of an application consuming disproportionate bandwidth.

Domotz Network Performance Reporting automatically runs speed tests every six hours and logs results in a searchable, filterable graph. This historical view makes it easy to correlate latency trends with business activity, identify degradation patterns over time, and build a documented case for infrastructure changes when needed.

---

Tools for Troubleshooting Network Latency

Each tool in the latency troubleshooting workflow serves a specific diagnostic purpose. Understanding what each one reveals helps you choose the right tool at each stage of the investigation.

• Ping is the starting point for any latency investigation. It sends ICMP echo requests to a target and returns RTT and packet loss statistics. It is best for confirming basic connectivity and establishing whether a problem exists, but it does not reveal where in the path the problem originates.
• Traceroute / Tracert maps the hop-by-hop path from source to destination, showing RTT at each router along the route. It identifies which segment of the path is introducing delay, making it the natural follow-up to a ping showing elevated latency.
• MTR (My Traceroute) combines ping and traceroute into a continuous monitoring session. It sends repeated packets and aggregates per-hop statistics over time, showing average RTT, best and worst RTT, and packet loss per hop. MTR is particularly effective for identifying intermittent problems missed by one-time traceroutes. Domotz Route Analysis is built on MTR and provides this capability natively in the monitoring interface.
• Curl provides detailed timing breakdowns for HTTP requests, separating DNS resolution time, TCP connection time, TLS handshake time, time to first byte, and total transfer time. It is useful for distinguishing network latency from application-level latency in web-based services.
• Netstat / SS provides TCP connection state and retransmission statistics. Elevated retransmission counts indicate packet loss being masked at the application layer, contributing to effective latency even when raw ping times appear acceptable.
• Network Path Analysis Tools such as Domotz Route Analysis visualize the full route with per-hop performance data aggregated over multiple test rounds, making them significantly more useful for production troubleshooting than single-run traceroute output.
• Flow Analysis (NetFlow / sFlow) provides visibility into traffic composition, top talkers, and bandwidth consumption patterns. This is the right tool when congestion is suspected and you need to identify which application or endpoint is responsible.

---

Common Latency Scenarios and Solutions

Applying the troubleshooting methodology to real-world scenarios illustrates how different root causes lead to different remediation paths.

Scenario 1: Consistently High Latency to a Distant Server

Cause: Geographic propagation delay. Traceroute will show latency building incrementally with each intercontinental hop, with no single problematic segment.

Solution: Deploy a CDN to cache content at edge nodes close to your users. Evaluate whether application workloads can be moved to a cloud region closer to the user base. Implement connection pooling to reduce the number of round trips required per session.

Scenario 2: Latency Spikes During Peak Business Hours

Cause: Network congestion from bandwidth demand exceeding available capacity. This pattern is typically visible in speed test history and correlates with business activity patterns.

Solution: Increase WAN bandwidth capacity where justified. Implement QoS policies to prioritize latency-sensitive traffic such as VoIP and video conferencing. Consider load balancing across multiple WAN links. Use flow analysis to identify and control specific applications consuming disproportionate bandwidth during peak hours.

Scenario 3: Intermittent High Latency with No Clear Pattern

Cause: This pattern most commonly indicates packet loss followed by TCP retransmission, duplex mismatches on specific interfaces, or hardware faults producing intermittent errors. Standard monitoring may not capture these events if they occur between sampling windows.

Solution: Review interface error counters on all devices in the suspected path. Check for duplex and speed mismatches. Inspect cable quality and SFP module health. Run MTR over an extended period to catch intermittent packet loss that single-run tests miss. Domotz packet loss monitoring runs continuously and can alert when loss exceeds a configured threshold, surfacing these events automatically.

Scenario 4: High Latency Only for Specific Users or Locations

Cause: ISP peering issues, inefficient BGP routing, or routing policy decisions causing traffic from specific source regions to take suboptimal paths.

Solution: Document the traceroute path from the affected location and compare it to a path from an unaffected location. Contact the ISP with documented evidence if suboptimal peering is identified. For enterprise environments with BGP capability, evaluate route optimization or traffic engineering options.

---

Latency Reduction Strategies

Once root causes are confirmed, these are the most effective approaches for reducing network latency in production environments.

• Use a CDN to cache static content at edge locations close to your user base, reducing propagation delay for the majority of user-facing requests.
• Implement Connection Pooling to reuse existing TCP connections for multiple requests rather than establishing new connections each time. This eliminates the latency overhead of repeated TCP handshakes.
• Enable HTTP Keep-Alive to maintain persistent connections between clients and servers, avoiding connection setup overhead on each request.
• Optimize DNS Resolution by implementing local DNS caching and reducing unnecessary DNS lookups. DNS resolution time is frequently overlooked as a contributor to perceived latency, particularly for applications that resolve many hostnames per session.
• Batch Requests where application architecture permits, combining multiple small API calls into single larger requests to reduce the cumulative overhead of round trips.
• Compress Data to reduce transmission delay, particularly on lower-bandwidth WAN links where transfer time is a meaningful contributor to total latency.
• Upgrade to HTTP/2 or HTTP/3 where possible. HTTP/2 supports request multiplexing over a single connection, eliminating head-of-line blocking. HTTP/3 uses QUIC, which further reduces connection establishment latency and handles packet loss more gracefully than TCP.
• Upgrade Hardware where device health checks reveal that processing delay is being introduced by aging or underpowered network equipment. CPU-bound routers and switches under sustained load add measurable latency to every packet they handle.

---

How Domotz Supports Latency Troubleshooting

Troubleshooting network latency effectively requires continuous data, not point-in-time snapshots. The difference between finding a root cause in minutes and spending hours chasing intermittent problems often comes down to whether the right data was being collected before the issue was reported.

Domotz provides the diagnostic and monitoring capabilities that support each stage of the troubleshooting workflow described above, without requiring a separate tool for each function.

Latency Monitoring in Domotz measures the delay from your network to external services, measured continuously toward Google’s public DNS. Historical values are logged so you can see exactly when latency began climbing and correlate that timing with other network events. Configurable alert thresholds notify you automatically when latency exceeds acceptable levels, rather than waiting for user complaints to surface the problem.

Route Analysis is built on MTR and lets you send test packets to any public internet server, choosing 10, 20, or 50 packets, and view hop-by-hop round-trip delay and packet loss statistics. This is the right tool for identifying where in the path a problem originates, without needing CLI access to network devices. It is accessible directly from the Collector Dashboard Network Performance section.

Bufferbloat Detection grades your internet connection’s performance under load, helping you identify whether excessive buffering is creating persistent high latency during periods of high utilization. Bufferbloat is a common cause of latency that is invisible to basic ping tests run during low-traffic periods, making it easy to miss without dedicated testing.

Jitter and Packet Loss Monitoring track two metrics that directly affect real-time application quality. Jitter, the variation in packet arrival times, degrades VoIP and video conferencing even when average latency looks acceptable. Continuous packet loss monitoring catches intermittent loss events that would otherwise accumulate into visible degradation before being reported.

Speed Tests run automatically every six hours and on demand, with results stored in a searchable, filterable graph. This historical baseline makes it straightforward to distinguish normal performance variation from genuine degradation, and to document the performance impact of infrastructure changes over time.

Comprehensive Network Reporting generates on-demand and scheduled reports covering latency, WAN performance metrics, downtime logs, and device performance data. For MSPs, this reporting supports client communication, SLA documentation, and evidence-based infrastructure investment conversations.

The Network Diagnostics capabilities in Domotz are built to reduce the time between a latency complaint and a confirmed root cause, and to surface issues proactively before users notice them.

If you want to see how Domotz performs in your environment, start a free trial and run your first Route Analysis within the first fifteen minutes of setup.

---

Conclusion

Troubleshooting network latency is a structured process, not a guessing game. High latency almost always has an identifiable cause, and most causes fall into a predictable set of categories: propagation distance, hardware health, congestion, misconfiguration, or routing inefficiency. Working through a systematic diagnosis, measuring first, identifying the contributing delay component, tracing the path, correlating metrics, checking device health, and analyzing traffic patterns, gives you a defensible path to a real fix rather than a series of changes made without confirmation.

The most important enabler of effective latency troubleshooting is continuous data collection. Teams that are already monitoring latency, packet loss, jitter, and bandwidth utilization when a problem surfaces have a significant advantage over those starting from zero. The evidence already exists. The investigation becomes interpretation rather than reconstruction.

Domotz provides that continuous monitoring layer alongside the diagnostic tools needed to investigate problems when they do occur, all in a single platform built for the networks MSPs and IT teams manage every day.

---

Frequently Asked Questions About Troubleshooting Network Latency