How to read the Agent Debug Log Report to trace one agent's session

An agent tells you their screen "froze" or "the button did nothing." That report is useless on its own — but VICIdial can show you almost exactly what their browser did, second by second. The Agent Debug Log Report records nearly every button click and back-end call function for one agent session across a time range.

It is incredibly detailed. A busy session can produce hundreds of entries per minute, so this is not a report you skim — it's one you search. Used right, it lets you replay an Agent session and pin down the exact moment something went wrong.

What the report actually captures

Two kinds of entries show up, and telling them apart is most of the skill:

• Front-end actions — the button clicks an Agent made: hangup, dispose, pause, transfer, and so on. These tell you what the agent was trying to do.
• Back-end AJAX call functions — the requests the agent screen fired to the server in response to those clicks. These tell you whether the server actually heard the click and answered.

A click with no matching back-end call right after it is the classic signature of a frozen screen: the browser registered the press but never reached the server. A back-end call that starts and then takes far too long to return points at the other end of the chain instead.

Where the fault usually lives

When an agent's screen misbehaves, the cause is almost always one of three things: the agent's network connection, the agent's workstation, or the database server the screen depends on. The debug log is how you decide which.

flowchart TD
  A[Click logged?] -->|No| B[Workstation or browser issue]
  A -->|Yes| C{Matching back-end call?}
  C -->|No| D[Network: request never reached server]
  C -->|Yes, slow return| E[Database server under load]
  C -->|Yes, fast return| F[Screen worked as designed]

If clicks aren't even being logged, suspect the workstation — a crashed tab, a blocked script, an overloaded machine. If clicks log but their back-end calls never appear, suspect the network between agent and dialer. If the calls appear but return slowly, suspect the database, especially during heavy reporting when query Latency climbs.

A practical reading routine

1. Pull the report for that one agent and the narrow window when the issue happened — minutes, not hours, given the entry volume.
2. Find the action the agent described, like the hangup that "did nothing."
3. Read the next few lines: did a back-end call follow, and did it return cleanly?
4. Note any gaps in time between a click and its response — those gaps are the bug.

This report tells you what the screen did, not how the connection performed over time. To see whether a slow workstation was lagging the whole session, pair it with the Agent Latency Report, and use the broader VICIdial troubleshooting playbook to decide which report to reach for first.

One more thing the log surfaces: if a screen action depends on an external CRM lookup, you'll see the back-end call sit there waiting on the third party rather than on your dialer — which saves you from blaming the wrong system.

On a VICIfast box this report is already available, and the database is sized so the debug log doesn't drag the rest of the system down when you switch it on. See what every plan includes.