Monitoring the Asterisk channel count on your VICIdial server

The Asterisk channel count in the Server Performance Report tells you how many live audio paths the server is carrying at any sampled moment, and tracking it alongside system load is the fastest way to tell whether a high-load spike is a real call surge or a software problem.

What a channel is

In Asterisk, a Channel is a single audio leg. Every call involves at least two channels: one toward the carrier Trunk and one toward the agent's phone. A bridged call that is also being recorded or monitored adds more channels on top. This means the channel count is not the same as the number of calls in progress — it is typically two to three times the call count depending on what features are active.

The Server Performance Report samples the live channel count every five seconds. The summary shows the average number of channels across the selected shift window. The graph shows how that number moved minute by minute, letting you see exactly when call volume peaked.

Average channels vs peak channels

The summary block gives you the average channel count for the window. Average channels is a good measure of typical utilization — how loaded the audio subsystem usually runs. But the graph's visual peak is what you need for capacity planning, because the summary average smooths out short bursts that can still stress the CPU.

A rising average over consecutive shifts means your campaigns are growing and the box is carrying more Concurrent calls every day. If the average keeps climbing while your headroom in the CPU IDLE percentage shrinks, you are approaching the limit of what the current hardware can handle.

Reading channels together with system load

The single most useful thing you can do with the channel count graph is overlay it mentally against the system load line. The two series move together for legitimate reasons and diverge when something is wrong. Here are the patterns to look for:

• Channels rise, load rises proportionally — normal call surge. The box is doing real work.
• Load spikes sharply but channels stay flat — a runaway process, a stuck database query, or a keepalive loop consuming CPU without carrying calls.
• Channels spike but load barely moves — you still have healthy spare capacity; the box is absorbing the burst without strain.
• Channels plateau while load keeps climbing — something outside of Asterisk is consuming resources; check the process count line.

flowchart LR
  A["Load spike"] --> B{"Channel count also up?"}
  B -->|Yes| C["Real call surge"]
  C --> D{"Load near core count?"}
  D -->|Yes| E["Consider resize or lower dial level"]
  D -->|No| F["Box absorbing it - OK"]
  B -->|No| G["Runaway process or stuck job"]
  G --> H["Check process count line"]
  H --> I["Restart offending service"]

What stuck channels look like

Occasionally a channel count will stay high after a campaign ends. Calls that did not hang up cleanly can leave zombie channels open, holding a SIP trunk leg and a small amount of CPU. If the channel count at the end of your shift is higher than you would expect given your agent count, check the Asterisk console for channels in state `Up` that have been live for an unusually long time and hang them up manually.

It is also worth knowing that Call recording adds channels. When a call is bridged and recording is active, Asterisk opens a third leg to write the audio stream. On a campaign where every call is recorded, your channel count is effectively three times the number of live conversations rather than two. That changes the math when you are comparing channel count to expected call volume — factor in recording when the numbers look higher than anticipated.

The channel count metric also helps you spot problems with Dialer pacing. If average channels are higher than the number of agents times two suggests they should be, the dialer may be placing more outbound legs than it is connecting — a sign that the Dial level is set too aggressively and calls are being abandoned before an agent can take them. Cross-referencing channel count against campaign drop rates lets you tune the dialer rather than resize the box.

For the full picture of how to interpret all four graph lines together — including the process count and the CPU USER/SYSTEM split — see how to read the Server Performance Report graphs.

Channel count is one signal in a broader set. For a structured approach to watching the whole server across shifts, the guide to monitoring VICIdial server health and capacity covers what to check and how often.

Want a managed box with performance logging on from the moment it provisions? Start a VICIfast trial and your server is running in under 40 seconds.