# 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` |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.console.zenlayer.com/welcome/elastic-compute/instance-monitoring/04-cpu-spend.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.