CloudWatch Metric Guide
node_cpu_utilizationAmazon EKS CloudWatch metric
node_cpu_utilization reports the total percentage of CPU units in use on a worker node (or aggregated across all nodes at the ClusterName dimension), calculated as node_cpu_usage_total ÷ node_cpu_limit — the node's total allocatable CPU capacity.
What it measures
About node_cpu_utilization
node_cpu_utilization reports the total percentage of CPU units in use on a worker node (or aggregated across all nodes at the ClusterName dimension), calculated as node_cpu_usage_total ÷ node_cpu_limit — the node's total allocatable CPU capacity.
| Namespace | ContainerInsights |
| Metric name | node_cpu_utilization |
| Unit | Percent |
| AWS docs | Official Amazon EKS metrics reference |
Why this metric matters
Node-level CPU saturation has a wider blast radius than any single pod running hot: the Kubernetes scheduler places pods based on requested CPU, not actual usage, so a node can look fully booked on paper while its real node_cpu_utilization climbs well past what was planned for. When that happens, every pod scheduled to the node is time-sliced against the same saturated physical CPU simultaneously — and pods that were never given a CPU limit can keep consuming whatever cycles remain, since Kubernetes only throttles pods against their own configured limit, starving neighboring pods that were sized more conservatively.
This is also a capacity-planning blind spot for autoscalers: Cluster Autoscaler and Karpenter react to pods that are unschedulable due to insufficient allocatable capacity, not directly to node_cpu_utilization. A workload where actual usage has drifted well above what pods originally requested can run a node hot indefinitely without ever triggering a scale-out event, because from the scheduler's perspective there's still "room" on the node. Monitoring node_cpu_utilization directly closes that gap.
Recommended alarm threshold for node_cpu_utilization
Recommended threshold
> 80% sustained for 15 minutes, evaluated per NodeName
AWS does not publish a universal alarm threshold for node_cpu_utilization. The 80%-for-15-minutes threshold (Nuberio recommendation) mirrors the pattern this guide uses for EC2 CPUUtilization — long enough to filter out brief bursts from pod startup, deploys, or garbage collection, short enough to catch a genuinely CPU-saturated node before every pod scheduled to it degrades together.
Is your node_cpu_utilization alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including node_cpu_utilization — in 5 minutes.
Common failures that show up in node_cpu_utilization
When node_cpu_utilization reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Pod CPU requests set well below actual usage, so the scheduler under-estimates true load when bin-packing pods onto the node
Missing or ineffective Horizontal Pod Autoscaler, so replica count doesn't grow with demand and existing pods burn more CPU per replica
Pods without CPU limits monopolizing available cycles on a shared node and starving neighboring, more conservatively-limited pods
A DaemonSet or cluster add-on (logging agent, service mesh sidecar, CNI plugin) consuming more CPU than budgeted for on every node in the cluster
Cluster Autoscaler or Karpenter scale-out lag — new nodes take time to join and become schedulable while existing nodes are already running hot
How the Nuberio Audit checks node_cpu_utilization
The free Audit scans every Amazon EKS resource in your account and checks whether a node_cpu_utilization alarm exists, whether its threshold and evaluation period are configured sensibly, and flags it if it's missing entirely. Every finding comes with the exact CLI command to fix it — read-only access, no credit card, results in about 5 minutes.
Nuberio Audit
Scans your CloudWatch setup for missing or misconfigured node_cpu_utilization alarms. Free, 5-minute read-only scan.
Related Amazon EKS metrics
node_cpu_utilization rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon EKS coverage.
FAQ
Frequently asked questions about node_cpu_utilization
Common questions about setting up CloudWatch alarms for node_cpu_utilization in Amazon EKS.
What is the recommended CloudWatch alarm threshold for node_cpu_utilization?+
> 80% sustained for 15 minutes, evaluated per NodeName. AWS does not publish a universal alarm threshold for node_cpu_utilization. The 80%-for-15-minutes threshold (Nuberio recommendation) mirrors the pattern this guide uses for EC2 CPUUtilization — long enough to filter out brief bursts from pod startup, deploys, or garbage collection, short enough to catch a genuinely CPU-saturated node before every pod scheduled to it degrades together.
Which CloudWatch namespace does node_cpu_utilization belong to?+
node_cpu_utilization is published in the ContainerInsights namespace with a unit of Percent. You can find it in the CloudWatch console under "Metrics" → "ContainerInsights". See the Amazon EKS CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for node_cpu_utilization?+
No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which Amazon EKS resources are missing a node_cpu_utilization alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a node_cpu_utilization alarm set up?+
Yes. The free Audit works whether or not you have any node_cpu_utilization alarm configured — it reads the resource directly from CloudWatch and tells you which resources need one, plus the copy-paste AWS CLI command to create it.
This page is part of the CloudWatch metric guide — thresholds and debugging guidance for every metric across RDS, Lambda, ECS, ALB, EC2, DynamoDB, SQS, API Gateway, S3, CloudFront, ElastiCache, and EKS. To find which Amazon EKS alarms your account is missing — including node_cpu_utilization — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.