VICIdial CPU time explained: USER, SYSTEM, and IDLE percentages

The USER, SYSTEM, and IDLE percentages in the Server Performance Report show how every CPU cycle on your VICIdial box is being spent, and the split between them tells you whether the processor is healthy, strained, or wasting time in the wrong place.

What each percentage measures

The three figures always sum to 100 %. Each represents a distinct category of CPU activity:

• USER — time the CPU spent on application-level work. This covers Asterisk processing audio, the VICIdial dialer engine managing Predictive dialing pacing, the web server handling browser requests, and any scripts running in user space. This is the productive fraction.
• SYSTEM — time the CPU spent on kernel-level work. This includes network packet handling, file I/O, memory management, and context switches between processes. A moderate SYSTEM figure is normal; a high one often indicates disk pressure or excessive network interrupts.
• IDLE — time the CPU had nothing to do. This is your headroom. As long as IDLE stays meaningfully above zero during busy periods, the box can absorb more load without degrading call quality.

What a healthy split looks like

On a busy but healthy VICIdial box, you typically see USER in the 30–50 % range, SYSTEM staying under 15 %, and IDLE holding somewhere above 30 % even at peak call volume. The exact numbers shift with call density, but the key signal is that IDLE never collapses to near zero except during short, isolated bursts.

A box with healthy numbers where USER does most of the work, SYSTEM stays modest, and IDLE provides a buffer will handle unexpected traffic spikes without agents noticing audio glitches or screen lag.

Warning signs in the split

Three specific patterns in the CPU split deserve immediate attention:

• IDLE near zero at peak — the box is out of CPU room. The next call surge will cause queuing, audio jitter, and agent screen delays. Either lower the Dial level or resize the server.
• SYSTEM creeping above 20 % — kernel overhead is consuming what should be user-space headroom. This often points to disk I/O pressure from call recordings filling a slow drive, or excessive network interrupt handling from a misconfigured SIP trunk.
• High USER but healthy IDLE — you are burning CPU on application work but still have room; this is a normal busy state, not a problem.

stateDiagram-v2
  [*] --> Healthy
  Healthy: IDLE above 30 percent
  Healthy --> Busy: USER rises with call volume
  Busy: USER 50-70 pct SYSTEM under 15 pct IDLE 20-30 pct
  Busy --> Strained: IDLE drops below 10 pct
  Strained: IDLE near zero at peak
  Strained --> Action: Audio jitter or agent screen lag
  Action: Lower dial level or resize server
  Strained --> SysHigh: SYSTEM above 20 pct
  SysHigh: Kernel overhead dominates
  SysHigh --> DiskCheck: Check disk IO and SIP interrupt rate

Using the graph to find the root cause

The Server Performance Report graphs the USER and SYSTEM percentages over time so you can see exactly when the split turns unhealthy. Look for the moment in the shift when IDLE compresses and then cross-reference it against the Channel count line on the same graph. If channels climbed in parallel, the CPU pressure is proportional to real call volume. If channels were flat when IDLE collapsed, a non-call process is the culprit.

A SYSTEM percentage that slowly climbs over several consecutive shifts without a matching rise in USER often means disk space is filling up and the kernel is spending more time on I/O wait. Call recordings accumulate quickly on a busy box. If SYSTEM has been trending up and the server-specific reports table shows a high hard-drive use percentage, clearing old recordings or moving them off the primary disk is the fix, not a CPU upgrade.

One practical threshold: if IDLE averages below 20 % across a full busy shift, not just at peak, you should plan a hardware upgrade before the next campaign ramp. At that point the box has less than one-fifth of its CPU capacity available for unexpected work. An AMD (answering machine detection) false-positive storm, a sudden influx of inbound calls hitting a DID (direct inward dialing) route, or a backup job kicking off mid-shift can push IDLE to zero and cause audio dropout.

The CPU metrics sit alongside system load and Asterisk channel count in the same report view. For guidance on reading all four graph lines as a set, see how to read the Server Performance Report graphs.

For a wider view of which server metrics to watch across a shift and what thresholds to act on, see the guide to monitoring VICIdial server health and capacity.

If sizing and performance tuning feel like a distraction from running campaigns, start a VICIfast trial and get a right-sized managed VICIdial box live in under 40 seconds with performance logging on from the start.