Diagnosing slow reports and why they can stall the whole system

A slow report feels like a minor annoyance until the afternoon a manager runs a wide date range and the agents on the floor start lagging at the same time. On a single-server setup the reporting queries and the live calling share one database, so a heavy report is not just slow for the person waiting — it can drag the entire dialer down. The Admin Report Log Viewer is where you go to catch the offender.

Why a report can hurt the whole box

Every page in the agent and admin interface ultimately reads and writes to the same database. A report that scans millions of call rows holds the database busy while it works. If that database is the same one feeding the live calling, the dialer pacing, agent screens, and even call setup all wait in line behind it. That is why a report's run time is an operational number, not just a convenience metric. A report that takes ninety seconds to compile is ninety seconds during which the box has less to give the live floor, and on a busy campaign that shortfall shows up fast.

What the Admin Report Log Viewer shows

This page lists the reports pulled from the system, 5000 per page. For each one you get:

• Report ID and the time and date it was retrieved.
• The user ID of the person who ran it and their IP address, so you know who to talk to.
• Which report it was, and the time in seconds it took to compile.

The run time is the field that matters. When a report has taken a long time to run, its run time appears in a highlighted colour, so the slow ones jump off the page without you scanning every row.

Turning a highlighted row into a fix

flowchart TD
  A[Open Admin Report Log Viewer] --> B{Any highlighted run times?}
  B -->|No| C[Reports are healthy]
  B -->|Yes| D[Note report user and date range]
  D --> E{Same report repeatedly slow?}
  E -->|Yes| F[Narrow its date range or schedule off-peak]
  E -->|No, one wide pull| G[Coach the user on tighter ranges]
  F --> H[Move reporting to a secondary DB server]
  G --> H

Start with the highlighted rows. Note which Real-time report or summary report is slow, who ran it, and how wide the window was. A single huge ad-hoc pull is a coaching problem — tighter date ranges fix it. The same report showing up slow every day is a structural problem, and the real answer is to run reporting against a secondary database server so heavy queries never touch the box placing calls.

Where to go next

For a full tour of every column and how to read the highlighting, see reading the Admin Report Log Viewer. If the slowdown shows up as agents falling behind rather than reports timing out, the broader checklist in the VICIdial troubleshooting playbook walks the rest of the path.

Splitting reporting onto its own database is the kind of architecture decision you would rather not be making at 4pm on a busy day. VICIfast runs sized, hardened VICIdial boxes that are live in under 40 seconds. See our plans and pricing.