CloudWatch Metric Guide
pod_cpu_utilizationAmazon EKS CloudWatch metric
pod_cpu_utilization reports the percentage of CPU units used by a pod (or aggregated by Namespace, Service, or ClusterName, depending on which dimension set you query), calculated as pod_cpu_usage_total ÷ node_cpu_limit — the node's total CPU capacity, not the pod's own CPU limit.
What it measures
About pod_cpu_utilization
pod_cpu_utilization reports the percentage of CPU units used by a pod (or aggregated by Namespace, Service, or ClusterName, depending on which dimension set you query), calculated as pod_cpu_usage_total ÷ node_cpu_limit — the node's total CPU capacity, not the pod's own CPU limit.
| Namespace | ContainerInsights |
| Metric name | pod_cpu_utilization |
| Unit | Percent |
| AWS docs | Official Amazon EKS metrics reference |
Why this metric matters
The formula AWS uses for this metric is easy to misread: pod_cpu_utilization is pod_cpu_usage_total divided by node_cpu_limit, the node's total CPU capacity — not the pod's own request or limit. That means a pod can show a low pod_cpu_utilization number on a large node while it's already being CFS-throttled against its own (much smaller) container limit. For OOM-adjacent, per-pod-limit CPU pressure specifically, pair this metric with pod_cpu_utilization_over_pod_limit; pod_cpu_utilization is the right signal for "how much of this node's real capacity is this pod actually consuming," which is what matters for bin-packing and node right-sizing decisions.
Because Container Insights publishes pod_cpu_utilization at four dimension granularities — PodName+Namespace+ClusterName, Service+Namespace+ClusterName, Namespace+ClusterName, and ClusterName alone — the same metric name works both as a per-pod diagnostic and as a namespace- or cluster-wide aggregate trend. A single noisy pod is a debugging problem; a Namespace-level pod_cpu_utilization that's been climbing for days across every pod in it is a capacity-planning problem that Horizontal Pod Autoscaler alone won't fix if its target is set too high.
Recommended alarm threshold for pod_cpu_utilization
Recommended threshold
> 80% sustained for 5+ minutes at the PodName+Namespace+ClusterName dimension for critical workloads
AWS does not publish a universal alarm threshold for pod_cpu_utilization. The 80%-for-5-minutes threshold (Nuberio recommendation) mirrors the pattern used for ECS and EC2 CPUUtilization alarms elsewhere in this guide — high enough to ride out normal request-driven CPU bursts, low enough to catch sustained pressure before CFS throttling meaningfully degrades request latency. Because the denominator is node_cpu_limit, re-tune the threshold if you change node instance types, since the same pod workload will read differently on a larger or smaller node.
Is your pod_cpu_utilization alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including pod_cpu_utilization — in 5 minutes.
Common failures that show up in pod_cpu_utilization
When pod_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 limit set too low relative to real usage, so the container gets CFS-throttled well before pod_cpu_utilization (measured against the node) looks alarming
Missing or misconfigured Horizontal Pod Autoscaler — target utilization set too high, or no HPA at all, so replica count doesn't grow with demand
A pod without a CPU limit monopolizing cycles on a shared node, which inflates this metric for every other pod scheduled to the same node since the denominator is shared node capacity
Runaway process or inefficient code path (unbounded retry loop, N+1 request fan-out, unbounded worker/goroutine spawn) consuming ever-increasing CPU
Node undersized for pod density — too many pods packed onto a node with a small node_cpu_limit inflates the percentage even when each pod's absolute CPU use is unremarkable
How the Nuberio Audit checks pod_cpu_utilization
The free Audit scans every Amazon EKS resource in your account and checks whether a pod_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 pod_cpu_utilization alarms. Free, 5-minute read-only scan.
Related Amazon EKS metrics
pod_cpu_utilization rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon EKS coverage.
FAQ
Frequently asked questions about pod_cpu_utilization
Common questions about setting up CloudWatch alarms for pod_cpu_utilization in Amazon EKS.
What is the recommended CloudWatch alarm threshold for pod_cpu_utilization?+
> 80% sustained for 5+ minutes at the PodName+Namespace+ClusterName dimension for critical workloads. AWS does not publish a universal alarm threshold for pod_cpu_utilization. The 80%-for-5-minutes threshold (Nuberio recommendation) mirrors the pattern used for ECS and EC2 CPUUtilization alarms elsewhere in this guide — high enough to ride out normal request-driven CPU bursts, low enough to catch sustained pressure before CFS throttling meaningfully degrades request latency. Because the denominator is node_cpu_limit, re-tune the threshold if you change node instance types, since the same pod workload will read differently on a larger or smaller node.
Which CloudWatch namespace does pod_cpu_utilization belong to?+
pod_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 pod_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 pod_cpu_utilization alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a pod_cpu_utilization alarm set up?+
Yes. The free Audit works whether or not you have any pod_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 pod_cpu_utilization — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.