CPU is usually the first metric anyone checks when a system feels slow, and iPM tracks it the same way across servers, network devices, and virtual machines, using whichever collection method that host type supports (SNMP, SSH, agent, or API — see Device Monitoring for the specifics per platform).
What's measured
- Overall CPU utilization, as a percentage
- Per-core utilization, where the underlying device or OS exposes it, since an average across cores can hide one core pinned at 100%
- Load average, on Linux/Unix hosts — a broader measure of demand on the system that includes processes waiting for CPU time, not just current usage
Setting thresholds
Every CPU check in iPM can have Warning and Critical thresholds. A common starting point is a Warning around 80% sustained utilization and a Critical around 95%, but the right numbers depend heavily on the host — a database server that regularly runs hot at 85% during business hours is very different from a lightly loaded utility server hitting the same number.
Avoiding alert fatigue
A brief CPU spike is normal and rarely worth waking someone up for. Where possible, pair a threshold with a duration — alert only if utilization stays above the threshold for a sustained period (for example, 5 minutes), not on a single high reading. This is usually configured as part of the alert condition rather than the check itself — see Alert Conditions in Alerts & Notifications.
Reading CPU alongside other metrics
Sustained high CPU is far more useful when read together with what else is happening on the host — a spike that lines up with a deployment or a scheduled batch job is expected; the same spike with no obvious cause is worth investigating. The dashboard's performance graphs make it easy to compare CPU against other metrics for the same host over the same time window.