How to read the Admin Report Log Viewer and spot slow-running reports

Your dialer feels sluggish at the same time every afternoon and you suspect a report is to blame. The Admin Report Log Viewer is where you confirm it. It lists every report anyone has pulled, along with how long each one took to compile, so you can find the one that is hammering the database.

What each row tells you

The viewer shows the reports pulled from the system, 5000 per page. Every row carries a report ID, the time and date it ran, the user ID of the person who pulled it, their IP address, the name of the report, and the compile time. That last column is the one you care about. When a report takes a long time to run, its compile time appears in a highlighted color so it jumps out of the list.

flowchart TD
  A[Open Admin Report Log Viewer] --> B[Scan compile time column]
  B --> C{Any rows highlighted}
  C -->|No| D[Reports are not the cause]
  C -->|Yes| E[Note report name]
  E --> F[Note user ID and IP]
  F --> G[Note time of day]
  G --> H[Decide fix or schedule]

Why a slow report hurts everything

Reports read from the same database the dialer uses to place calls and update agent screens. A heavy report holds locks and burns query time, so the dialer waits in line behind it. The symptom looks like rising Latency: agent screens lag, calls take longer to connect, and your live Real-time report numbers drift from reality. None of that is a dialing bug. It is a report starving the box.

The clean fix is to run reports against a secondary database server so heavy queries never touch the box that runs calls. Without that split, every long-running report competes with live dialing on the same hardware. On a small single-server setup you may get away with it for a while, but as call volume and history grow, the same report that once compiled in two seconds starts taking thirty, and the dialer feels it. The viewer is how you catch that drift before agents start complaining.

A useful habit is to skim the viewer once a week even when nothing feels wrong. You are looking for two things: reports whose compile time is creeping up over the weeks, and reports being pulled far more often than anyone needs. Both are cheaper to fix early. A report that someone leaves open and refreshes every minute can do as much damage as one slow query, because it never lets the database breathe.

How to trace the offender

1. Open the viewer and scan the compile time column for highlighted entries. The color does the work of finding the slow ones for you.
2. Read across that row for the report name. This tells you which report is expensive, not just that one exists.
3. Note the user ID and IP address. This is who ran it, so you can ask them to schedule it off-peak or stop pulling it on the live server.
4. Match the time and date against your latency spikes. If the highlighted runs line up with the slow window, you have your cause.

Treat the viewer as a KPI for your reporting load, not just a log. A growing pile of highlighted rows during business hours is a sign you have outgrown a single-server setup and need a reporting replica or a bigger VPS. For the broader method, follow the troubleshooting playbook, and if the slowness shows up in your live numbers too, cross-check with the real-time monitoring log report. To skip the database-tuning entirely and let someone size the box for you, see VICIfast pricing.