What causes latency gaps on the agent screen

A Latency gap is a period where an Agent's browser stops sending keep-alive requests to the server while the agent is supposed to be logged in. The Latency Gaps Report shows you when and how long these gaps occurred, but it does not tell you why. That diagnosis requires understanding the four main categories of cause and matching each against the pattern you see in the report.

Agent-side network interruptions

The most common cause of gaps for individual agents is an unstable network connection between the agent's computer and the server. Wireless connections are the usual culprit — a laptop on Wi-Fi that roams between access points, a wireless adapter that goes into power-saving mode, or a congested router that drops packets for a few seconds. These events appear as repeated short gaps for one agent while other agents show clean logs.

VPN tunnels are another common source. Many VPNs drop and renegotiate the tunnel periodically, which creates a gap each time the reconnect takes more than a few seconds. Agents using split-tunnel VPNs can also see gaps if the routing rules push agent screen traffic through a congested VPN path while voice traffic takes a different route.

Browser and workstation causes

Browsers can pause background tabs when they decide to throttle idle pages. If an agent minimizes their browser or switches to another application, some browsers will reduce the frequency of timer-driven JavaScript, which includes the keep-alive loop on the agent screen. This creates a gap that starts when the tab is backgrounded and ends when the agent brings it back to the foreground.

A workstation under heavy CPU load — antivirus scans, software updates, or another application consuming resources — can also cause the browser's JavaScript timer to fire late. This usually shows up as a single large gap during the event rather than a pattern of frequent small gaps.

Network Jitter and packet loss between agent and server

Jitter — variation in packet delivery time — and Packet loss on the path between the agent and the server can both cause gaps. Unlike a full connection drop, these conditions allow some packets through while others are delayed or lost. The browser's HTTP keep-alive may time out waiting for a response, causing the log entry to be missed, and then succeed on the next attempt once the path clears.

Agents on the same office network but using a shared internet connection that becomes saturated during business hours show this pattern — gaps that are irregular but tend to cluster at the same times each day when bandwidth usage is highest. This also tends to correlate with reports of degraded voice quality, since audio RTP streams are affected by the same path problems.

Server-side overload

flowchart TD
  A["Latency gap detected"] --> B{"Affects one agent or many?"}
  B -->|"One agent"| C{"Frequent short gaps?"}
  C -->|Yes| D["Agent network or Wi-Fi instability"]
  C -->|No| E["Browser tab backgrounded or CPU spike"]
  B -->|"Many agents"| F{"Coincides with peak call volume?"}
  F -->|Yes| G["Server overload — dial level too high"]
  F -->|No| H{"Specific time of day?"}
  H -->|Yes| I["Shared bandwidth saturation"]
  H -->|No| J["Server-side event — check process logs"]

When the server is under heavy load, the web tier may take so long to respond to keep-alive requests that the connection times out on the agent's browser before a response arrives. This creates a gap even when the network path is perfectly healthy. Server-side gaps affect many agents at the same time and correlate with high system load, high Concurrent calls counts, or a process that is consuming resources unexpectedly.

A database issue — a slow query, a table lock, or a replication lag on a multi-server setup — can also block the keep-alive response for all agents simultaneously. These events appear as a single gap affecting everyone at the same moment, then resolving when the database condition clears.

Matching cause to fix

Once you have identified the pattern in the Latency Gaps Report, the fix follows from the cause. For one-agent problems, start with the agent's workstation and network. For shared-bandwidth problems, look at internet connection sizing for the office. For server overload, compare the gap timestamps with the Server Performance Report to confirm load was high, then either reduce the Dial level at peak times or move to a larger server.

For more on tracking server capacity trends over time, see the server health and capacity monitoring guide. For an explanation of what the system load number means during those events, see what peak system load tells you.

If server overload is a recurring cause of gaps, it may be time to look at a larger box — see VICIfast plans for sizing options, with provisioning in under 40 seconds.