> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/elastic-compute/instance-monitoring/04-cpu-spend.md).

# How Is My CPU Actually Being Spent?

These panels break down CPU time by where it was spent, so you can attribute load to user code, kernel work, I/O wait, and other states.

## CPU Utilization

Aggregate CPU busy ratio of the guest — `1 − idle`. The first thing to look at when CPU climbs.

## CPU User

Time the guest spent running user-space code. The first line of attribution for application owners — if this is high, profile your application.

## CPU System

Time the guest kernel spent on syscalls and kernel-side work on behalf of user processes. High system time with low user time usually points at syscall storms, network softirq pressure, or contended kernel locks.

## CPU IOWait

Time the CPU was idle while there was at least one outstanding I/O request. Read together with the disk panels and Hypervisor I/O Wait Time to localize whether the bottleneck is in the guest or in the storage backend.

## CPU SoftIRQ

Time spent servicing software interrupts — dominated by network RX/TX processing on busy VMs. Sudden growth here is a strong hint that the instance is approaching a packet-per-second limit.

## CPU Idle

The complement of CPU Utilization. Surfaced explicitly so you can spot "idle but unhappy" patterns: high idle combined with high IOWait or high CPU Other.

## CPU Other

Catch-all bucket for the less common CPU states. **Important:** this is also where guest-observed steal time lives. If CPU Other climbs without CPU User or CPU System climbing, suspect host over-provisioning and cross-check with **Hypervisor CPU Queue Time** ([Q1](/welcome/elastic-compute/instance-monitoring/01-overprovisioning.md)).

## Hypervisor CPU Time / User / System

The total CPU the hypervisor billed to this domain — measured on the host side, not from inside the guest. Broken down into total time, user-space time, and kernel time. Useful when reconciling guest-side CPU spend with hypervisor-side capacity planning, and as a fallback when in-guest data is unavailable.

## Hypervisor I/O Wait Time

Time the vCPU was blocked on I/O, measured on the host side. Read together with the disk latency panels ([Q5](/welcome/elastic-compute/instance-monitoring/05-disk.md)) to localize I/O stalls.

## API Reference

All instance metrics use `DescribeInstanceMonitorData` with the `metricType` values below.

| Console Panel            | metricType                |
| ------------------------ | ------------------------- |
| CPU Utilization          | `CPU_UTILIZATION`         |
| CPU User                 | `PROC_CPU_USER`           |
| CPU System               | `PROC_CPU_SYSTEM`         |
| CPU IOWait               | `PROC_CPU_IOWAIT`         |
| CPU SoftIRQ              | `PROC_CPU_SOFTIRQ`        |
| CPU Idle                 | `PROC_CPU_IDLE`           |
| CPU Other                | `PROC_CPU_OTHER`          |
| Hypervisor CPU Time      | `HYPERVISOR_CPU_TIME`     |
| Hypervisor CPU User      | `HYPERVISOR_CPU_USER`     |
| Hypervisor CPU System    | `HYPERVISOR_CPU_SYSTEM`   |
| Hypervisor I/O Wait Time | `HYPERVISOR_IO_WAIT_TIME` |