What the average channels-in-use number means

The average channels-in-use figure on the Server Performance Report is the mean number of simultaneous Asterisk audio paths the server carried at any sampled moment during the shift — it is the single best shorthand for how busy the dialer actually kept the box.

What a channel is

Every leg of every call occupies one Channel inside Asterisk. A simple outbound call between one Agent and one contact uses two channels: one for the agent's phone leg and one for the contact's line. Add a SIP trunk leg for the carrier, and you can have three. Ring a group of agents for an inbound call and you get one channel per ring target. The channel count is therefore a coarser but more stable number than raw call count — it reflects actual audio-path load on the CPU, memory, and network interface simultaneously.

The report samples this count every five seconds, then averages all those readings across the window you select. The result smooths out momentary spikes and gives you a reliable baseline for the shift.

Average versus peak

Average channels-in-use and peak channels-in-use measure different things. The average tells you what the server handled most of the time. The peak tells you the worst-case simultaneous load the hardware had to absorb. Both matter, but for different decisions:

• Average is the right number for comparing shifts. A Monday average of 18 channels versus a Friday average of 32 channels shows your week-end push clearly.
• Peak is what you size hardware and trunk capacity against. Your Carrier trunks and server must handle the peak without degradation, not just the average.
• A high average with a low peak suggests steady, predictable load. A low average with a sharp peak suggests burst calling patterns — either a predictive surge or a large inbound event.

Reading channels alongside system load

The real value of the channels-in-use figure appears when you put it next to the system load number. These two figures, plotted on the same graph in the Server Performance Report, let you separate genuine call pressure from software problems.

flowchart TD
  A["Load spikes on graph"] --> B{"Channels rising too?"}
  B -->|"Yes"| C["Real call surge"]
  C --> D["Lower [[dial-level]] or add capacity"]
  B -->|"No"| E{"Process count up?"}
  E -->|"Yes"| F["Runaway process or stuck job"]
  F --> G["Restart the offending service"]
  E -->|"No"| H["Check SYSTEM CPU or disk IO"]

When load rises and channels rise together, the server is genuinely processing more calls than usual. The right response is to consider whether your hardware headroom is being approached. When load rises but channels stay flat, something other than calls is consuming the server — a stuck process, a database query loop, or a runaway script. Chasing that problem through campaign settings would be wasted time.

A healthy box at a predictive Dialer pacing setting typically shows channels moving in lock-step with system load. When the two diverge, investigate.

Using the number over time

Track the average channels-in-use across consecutive shifts and you will see whether your calling operation is growing, shrinking, or holding steady. If the average climbs week over week while your agent head-count stays constant, you are likely running a higher Auto dial level or your campaigns are connecting at a better rate — both of which push more audio legs through the server.

When the average reaches roughly 60 to 70 percent of the server's comfortable ceiling, it is time to plan a resize. By the time the average hits the ceiling, you have already had painful peaks above it.

For the broader framework of what to check and how often, see our guide to monitoring VICIdial server health and capacity. For a full walkthrough of every field on the Server Performance Report, including load and CPU breakdowns, read how to read the Server Performance Report.

Want performance logging enabled from the first boot without touching a config file? Start a VICIfast trial and get a fully configured VICIdial server live in under 40 seconds.