How to read the Agent LAGGED Report to find which dialer is struggling

When agents complain that the screen "hangs" for a second or two, that's lag — and VICIdial records it. The Agent LAGGED Report is two reports in one: a short list that names the dialer responsible, and a detailed list of every lagged event. Read them together and you can tell whether one server is sick or the whole cluster is.

What "lagged" means here

A lagged event is logged when the Agent session takes longer than expected to respond — the agent's screen and the dialer briefly fall out of sync. It's not the same as a dropped login; the Agent stays connected, but the experience stutters. Set a date and time frame and the report fills in everything that happened in that window.

Report one: which dialer is struggling

The first report is the one you read first. It shows the server IP of the dialer that experienced the lag, plus the total number of times lag occurred on it. On a single box that's just a count. On a cluster — or any environment with more than one server — this is the line that tells you where to point. One IP carrying most of the lagged events is your suspect VPS; lag spread evenly across IPs points at something shared, like the network or the database.

Report two: every lagged event in detail

The second report lists each lagged event with the fields you need to reproduce it: agent log ID, user ID, server IP, the event time, lead ID, Campaign, status, User group, the Dial method in use, and the unique ID. That's a full fingerprint per lag.

• User ID + event time → ask that agent what they saw at that exact moment.
• Server IP → confirms it matches the dialer from report one.
• Campaign + dial method → tells you whether predictive pacing was pushing the box hard at that time.
• Unique ID → ties the lag to the specific call so you can trace it elsewhere.

A reading order that works

flowchart TD
  A[Agents report screen hangs] --> B[Read report one: server IPs]
  B --> C{Lag on one IP?}
  C -->|Yes| D[Drill into that dialer in report two]
  C -->|No| E[Shared cause: network or database]
  D --> F{Same campaign and dial method?}
  F -->|Yes| G[Suspect pacing or load on that box]
  F -->|No| H[Look wider at server health]

Connecting lag to load

The dial method and campaign columns matter more than they look. If the lagged events cluster on a campaign running aggressive Predictive dialing, the box may simply be doing too much at once — Asterisk, the database, and the web server all competing for the same CPU. Lag is often the first visible symptom of an under-resourced server before anything actually breaks.

For the wider session story, follow this with the LAGGED Summary Report, which charts these same events over time so you can see whether the lag is constant or bursty. Both reports live inside the VICIdial troubleshooting playbook.

When the fix is more server

If report one keeps naming the same dialer and report two keeps blaming a heavy campaign, you've found an undersized box, not a bug. The right move is to give that dialer more room. VICIfast sizes each dedicated server to the campaign load and resizes without downtime — see the plan tiers to match capacity to your agent count. Read the two reports in order, and lag stops being a mystery: you'll know the server, the agents, and the campaign behind every stutter.