How to read the Campaign Debug Page

The Campaign Debug Page shows you the dialer's own internal log lines for a single Campaign, filtered in real time, so you can see exactly what the back end is doing instead of guessing from the outside.

Where to find it and how to open it

The page lives in Admin Utilities at the bottom of the main Reports menu. When you open it, you will see a campaign selector. Pick the campaign you want to inspect and the page immediately begins streaming the dialer's log output for that one campaign. There is no date range to configure and nothing to enable ahead of time — the debug output is always running in the background; this page just pulls it to the surface for you.

What the log lines tell you

Each log line is timestamped and describes one action the dialer engine took or one decision it made. The most useful signals for diagnosing a campaign that has gone quiet fall into three areas:

• Hopper loads — lines that record how many Lead records were placed into the Hopper (the short queue of numbers ready to dial). If you see hopper loads of zero repeatedly, the campaign has run out of eligible leads, hit a Lead filter that is excluding everything, or the lead-loader process is not running.
• Dial-level calculations — the dialer prints its current Auto dial level each cycle. If the number is staying at 1.0 when you expect it to climb, watch the available-agent count printed beside it. A healthy predictive campaign needs agents in a ready state; if no agents are available the dial level cannot rise.
• Calls placed and outcomes — each outbound attempt is logged with the number dialed and what happened to it. If the dialer is placing calls but they all fail immediately, look for error strings in the outcome field. Those strings usually point to a trunk or dialplan problem rather than a campaign configuration issue.

Reading the debug output when a campaign stops dialing

A campaign that stops dialing almost always falls into one of three failure modes. The debug log makes them easy to tell apart:

flowchart TD
  A["Campaign not dialing"] --> B{"Hopper size > 0?"}
  B -->|No| C["No eligible leads"]
  C --> D["Check lead list, filters, or loader"]
  B -->|Yes| E{"Agents available?"}
  E -->|No| F["Agents not in ready state"]
  F --> G["Check agent sessions and status"]
  E -->|Yes| H{"Calls placed but failing?"}
  H -->|Yes| I["Trunk or dialplan error"]
  I --> J["Check Asterisk Debug Page"]
  H -->|No| K["Check dial level and pacing settings"]

Work top to bottom. Start with hopper size. If the hopper is empty, no amount of agent availability or dial-level tuning will produce calls — the lead side is the problem. If the hopper has records but calls are not going out, look at the agent count on the same line. If calls are going out but failing, the problem is outside the campaign configuration and the Asterisk Debug Page is where you look next.

Pacing problems and what to look for

When a campaign is dialing but pacing feels off — too slow, too fast, or inconsistent — the debug log shows the Dialer pacing calculation on each cycle. You can see the current abandon rate the system has measured, the target Drop percentage limit, and the adjustment the dialer made to the dial level as a result. If the dialer is holding back because the abandon rate is already at the limit, that is correct behaviour. If it is holding back for no apparent reason, check whether the call duration data is stale or whether one agent has been in a very long call that is skewing the average handle time the algorithm uses.

For the broader context of what a healthy server looks like while a campaign is running, see the guide to monitoring VICIdial server health and capacity. For server-level performance data alongside campaign activity, the Server Performance Report shows load, channels, and CPU in the same window.

Want a managed box where every campaign debug page is ready from day one? Start a VICIfast trial and have a fully configured VICIdial server live in under 40 seconds.