A Kubernetes cost dashboard tells your team something your cloud bill cannot: which namespace, workload, or team is driving spend. Cloud billing surfaces totals at the cluster level. To find and fix waste, your platform team needs visibility at the namespace and workload level. This guide covers the Kubernetes cost metrics that belong in every cost visibility dashboard, how to build the views with Prometheus, Grafana, and OpenCost, and how to connect those signals to actionable cost reductions.
Key takeaways #
- Cloud billing does not show per-namespace or per-workload cost. A Kubernetes cost dashboard fills that gap.
- Every dashboard should surface ten core metrics: cost per namespace, cost per workload, CPU request utilization ratio, memory request utilization ratio, idle node cost, CPU waste, memory waste, workload efficiency score, monthly trend, and GPU utilization.
- According to Cast AI’s 2026 State of Kubernetes Optimization Report, average CPU utilization is 8% across 23,000+ production clusters. Memory averages 20%. GPU utilization averages just 5%.
- CPU overprovisioning jumped from 40% to 69% year-over-year (Cast AI 2026 State of Kubernetes Optimization Report), affecting 23,000+ production clusters. Without a dashboard, teams cannot see where that padding accumulates.
- Prometheus, Grafana, and OpenCost let you build these views from open-source tooling. Cast AI provides them out of the box, free for unlimited clusters, with automated optimization layered on top.
The metrics that matter in a Kubernetes cost dashboard #
Your cloud bill shows a monthly total. That total gives you nothing to act on. The first job of a Kubernetes cost metrics layer is to break that total into units your team can investigate: namespaces, workloads, and nodes. Each metric below answers a specific operational question. Treat it as a checklist, not a menu.
Why each metric earns its place
Platform teams often start with cluster-total cost and find it useless for daily decisions. The table below maps each metric to what it measures, why it matters, and which tool computes it. The tool column matters because some metrics require a cost model (OpenCost or Cast AI), while others come directly from Prometheus with kube-state-metrics already running.
| Metric | What it measures | Why it matters | Tool |
|---|---|---|---|
| Cost per namespace | Total compute spend attributed to a namespace per period | Maps spend to a team or environment; the first accountability unit for showback and chargeback | OpenCost, Kubecost, Cast AI |
| Cost per workload / deployment | Compute cost per Deployment, DaemonSet, StatefulSet, or Job | Identifies expensive workloads and rightsizing candidates | OpenCost, Cast AI, Kubecost |
| CPU request utilization ratio | Actual CPU usage divided by CPU requested (0.0 to 1.0) | Values below 0.5 signal padding; each 10-point gap wastes provisioned budget | Prometheus + kube-state-metrics |
| Memory request utilization ratio | Actual memory (working set) divided by memory requested | Average memory utilization is just 20% across 23,000+ production clusters, making it the largest hidden cost lever (Cast AI 2026 State of Kubernetes Optimization Report) | Prometheus + kube-state-metrics |
| Idle node cost | Cost of capacity with no pods scheduled (node cost minus pod cost) | Direct, attributable waste; shows when nodes should be consolidated or removed | OpenCost, Grafana Cloud Kubernetes Monitoring |
| CPU waste (cores) | Requested CPU minus actual usage, per namespace or workload | Translates the utilization ratio gap into an actionable resource number | Prometheus PromQL recording rule |
| Memory waste (bytes) | Requested memory minus working set, per namespace or workload | Memory waste is often larger than CPU waste in absolute dollar terms | Prometheus PromQL recording rule |
| Workload efficiency score | (Usage / Requests) × 100 for CPU and memory combined | Single composite score that enables dashboard alerts and efficiency SLA targets | Kubecost, OpenCost, Cast AI |
| Monthly cost trend and forecast | Rolling daily spend extrapolated to end-of-month | Enables budget guardrails and early anomaly detection before the month closes | Cast AI, Kubecost, custom PromQL recording rule |
| GPU utilization | Actual GPU usage per workload versus provisioned GPU capacity | H100 GPUs run $100–200/day on-demand (AWS p5, GCP A3, Azure ND H100 v5 series); industry average utilization is just 5% | Cast AI, DCGM Exporter + Prometheus |
The metrics in the top half of the table (cost per namespace, cost per workload) require a cost model: a mapping from node pricing to pod resource consumption. OpenCost or Cast AI both provide this. The utilization ratios in the middle rows come from raw Prometheus metrics without any cost model at all. Start with utilization ratios if Prometheus is already running. Layer in cost attribution once OpenCost is deployed.
Teams use namespace cost data in two ways. Showback means distributing cost reports to team leads for visibility; no money changes hands, but accountability follows the data. Chargeback means billing team budgets directly, which requires tighter label discipline and a signed-off cost allocation policy. Start with showback; move to chargeback once your labeling coverage exceeds 90%.
Building the Kubernetes cost dashboard: Prometheus, Grafana, and OpenCost #
Building a cost visibility dashboard from open-source tooling takes three components: Prometheus for metric collection, OpenCost for cost attribution, and Grafana for visualization. Each layer is independently useful. All three together unlock every metric in the table above.
Deploy the Prometheus cost dashboard stack
First, deploy kube-prometheus-stack via Helm with at least 90 days of retention and 100Gi storage. This gives you kube-state-metrics and node-exporter by default. Next, deploy OpenCost using the official Helm chart:
helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm install opencost opencost/opencost --namespace opencost --create-namespace
OpenCost is a CNCF Incubating Project that reads Prometheus metrics and cloud pricing data, then exports per-container cost metrics back into Prometheus on port 9003. Add a Prometheus scrape job targeting OpenCost on port 9003 with a one-minute scrape interval. The following OpenCost-exported metrics then become available for PromQL queries: node_total_hourly_cost
, container_cpu_allocation
, node_cpu_hourly_cost
, and node_ram_hourly_cost
. These are the foundation for cost-per-namespace and idle cost calculations.
Labels are the prerequisite for everything
Before building any of these views, check your labeling strategy. Kubernetes labels on pods (team, service, environment) propagate into Prometheus via kube-state-metrics. Without those labels, you cannot split cost across allocation groups. This is the most common reason teams build a Prometheus cost dashboard and then discover they cannot answer “which team owns this spend?”
Establish a labeling convention first. Deploy OpenCost. Build the views. Skipping the labeling step means rebuilding your dashboard queries after they are live, which is far more disruptive than getting it right upfront.
Three PromQL queries to build first
These queries cover the most impactful views. Define them as Prometheus recording rules so Grafana dashboards load quickly even over a 90-day range.
CPU utilization ratio per namespace:
sum by (namespace) (rate(container_cpu_usage_seconds_total[5m]))
/ sum by (namespace) (kube_pod_container_resource_requests{resource="cpu"})
This query shows how much of your requested CPU is actually in use. A ratio of 0.08 means a namespace uses 8% of what it requested; that is exactly the average Cast AI observes across 23,000+ production clusters. When you first run this query, results below 0.3 are common and expected.
Monthly CPU cost per namespace (requires OpenCost metrics):
sum(container_cpu_allocation * on (node) group_left node_cpu_hourly_cost) by (namespace) * 730
This query multiplies each container’s CPU allocation by its node’s hourly CPU cost, then projects to a monthly figure using 730 hours. This becomes the cost per namespace number your finance or FinOps team expects for showback reporting.
Idle node cost per node (requires OpenCost):
sum by (node) (
node_total_hourly_cost
) - sum by (node) (
container_cpu_allocation * on(node) group_left() node_cpu_hourly_cost
+ container_memory_allocation_bytes / 1024 / 1024 / 1024 * on(node) group_left() node_ram_hourly_cost
)
Idle cost is the difference between what a node costs and what the pods on it have claimed. This query returns idle cost in dollars per hour. Multiply by 730 for monthly idle cost. Nodes with high idle cost are consolidation candidates. This metric also surfaces unscheduled capacity that the cluster autoscaler provisioned in response to inflated resource requests.
GPU utilization (requires DCGM Exporter):
For GPU cost monitoring, deploy the NVIDIA DCGM Exporter alongside OpenCost. It surfaces DCGM_FI_DEV_GPU_UTIL
(utilization %) and DCGM_FI_DEV_FB_USED
(memory used in MiB). The cost dashboard for GPU is built from those metrics. If utilization sits below 20% consistently, idle GPU nodes are provisioned at idle cost.
avg by (GPU_I_ID, node) (DCGM_FI_DEV_GPU_UTIL)
For most teams, this is the single highest-ROI metric to act on first.
Grafana community dashboards to import
Once your Prometheus and OpenCost stack is running, import these community dashboards directly from Grafana’s dashboard library. Each requires the OpenCost or Kubecost exporter to be scraping into Prometheus first.
Kubernetes Cost Report(ID 15877): cost breakdown by namespace and workload, sourced from Kubecost** Exec Kubernetes Cost Report**(ID 15874): executive summary of cluster cost, useful for leadership reporting** Cluster Cost and Utilization Metrics**(ID 8670): cluster-level compute cost and utilization in one view
Grafana Cloud Kubernetes Monitoring uses an allocation algorithm combined with OpenCost hourly cost estimates for CPU and memory at container, pod, namespace, and workload levels. This integration removes the need to self-manage the OpenCost deployment, though it ties your cost visibility to Grafana Cloud’s billing.
Idle capacity and efficiency #
The utilization numbers from Cast AI’s 2026 State of Kubernetes Optimization Report make the idle capacity problem concrete. Average CPU utilization sits at 8% across 23,000+ production clusters. Memory averages 20%. GPU utilization averages 5%. CPU overprovisioning jumped from 40% to 69% year-over-year. These are not outlier clusters. These are production workloads running at scale.
Why teams overprovision structurally
These numbers reflect a structural pattern, not individual mistakes. Teams pad resource requests to avoid OOM evictions and CPU throttling. The cost of that padding stays invisible to the team responsible. Helm chart defaults use conservative estimates across services. The cluster autoscaler treats inflated requests as genuine demand and provisions excess nodes to match. The result is idle capacity that accumulates silently, month after month.
Your cloud bill shows the node running. It does not show that 92% of its CPU is idle. Idle cost requires an explicit metric, not an inferred one. H100 GPUs run $100–200/day per GPU on on-demand pricing (AWS p5, GCP A3, Azure ND H100 v5 series). At $150/day per GPU at 65% idle, 32 GPUs waste roughly $3,120/day in idle GPU cost, or $93,600/month. Without sub-minute telemetry and a dedicated idle cost panel, those figures do not appear in any report.
Reading the efficiency score
The efficiency score formula clarifies this at the workload level:
Efficiency = (Resource Usage / Resource Requests) × 100
A workload at 100% efficiency uses exactly what it requests. Most production workloads run well below that. The goal is not 100%: headroom for traffic spikes is legitimate engineering practice. The goal is visibility, so your team can distinguish intentional headroom from forgotten padding set in a Helm chart six months ago.
Set an alert threshold: flag any workload with an efficiency score below 20% for 7 consecutive days. That threshold surfaces systematic over-padding rather than temporary underutilization. Review flagged workloads manually or route them to an automated rightsizing system.
How Cast AI connects visibility to action #
A Prometheus and Grafana stack tells you that a namespace is running at 8% CPU utilization. That is the visibility layer. Closing that gap requires someone to right-size every flagged workload, track the results, and repeat. Cast AI’s Kubernetes cost monitoring platform completes that loop automatically.
Cast AI provides free, real-time cost monitoring for unlimited clusters, with no billing access required. The platform uses public cloud pricing data, so your team gets cost visibility without sharing cloud credentials. Three outcomes matter most: your engineering team sees cost drill-downs per workload and namespace refreshed every 60 seconds; your FinOps team gets a monthly forecast with percent change versus the prior month and cost anomaly alerts before the month closes; and your GPU operators get per-workload utilization data before they provision more capacity. Teams managing multiple clusters get aggregated cost data across all of them in a single Cast AI dashboard. No separate Grafana federation setup required.
Beyond monitoring, Cast AI’s workload autoscaling adjusts CPU and memory resource requests based on actual consumption. The gap your dashboard surfaces closes automatically, without ongoing engineering work. One Cast AI case study found OOM kill rates dropped near-zero after automated rightsizing deployed, even as provisioned CPU was cut by roughly half. The dashboard shows that a namespace is at 8% CPU utilization. Cast AI drops the bill without a ticket.
Cast AI reads standard kube-state-metrics and OpenCost data. Your cluster metrics stay in your infrastructure, and there is no vendor lock-in at the monitoring layer.
Conclusion #
Your Kubernetes cost dashboard shows the gap precisely: 8% CPU utilization, 20% memory, 5% GPU. Every hour those numbers sit in Grafana without an automated response, idle capacity compounds. The visibility step is complete once your queries are running. Cast AI closes the gap: it rightsizes workloads, consolidates idle nodes, and recovers GPU waste automatically, without manual alert triage.
Visibility is the first step. The second step is allocation: once your dashboard shows where cost lives, you need a method to assign it to the right team. Allocation is how costs are split; dashboards are how you see them. Both are required for a complete FinOps practice.
If you want these views without managing the Prometheus stack yourself, Cast AI’s cost monitoring is free for unlimited clusters. Connect your cluster and get real-time cost dashboards in minutes.
Frequently Asked Questions #
What should a Kubernetes cost dashboard show? A Kubernetes cost dashboard should show cost per namespace, cost per workload, CPU request utilization ratio, memory request utilization ratio, idle node cost, CPU waste, memory waste, workload efficiency score, monthly cost trend and forecast, and GPU utilization. These ten metrics give your team the visibility to locate waste at the namespace and workload level, assign accountability to teams, and track efficiency over time. Start with utilization ratios from Prometheus, then layer in cost attribution with OpenCost or Cast AI.
What metrics matter for Kubernetes cost? The most actionable Kubernetes cost metrics are cost per namespace (the primary accountability unit for showback), CPU request utilization ratio (signals overprovisioning at the namespace level), idle node cost (direct waste not visible in cloud billing), and workload efficiency score (composite signal for rightsizing candidates). Together, these metrics surface where spend is going, which namespaces or workloads are over-padded, and which nodes should be consolidated. According to Cast AI’s 2026 State of Kubernetes Optimization Report, average CPU utilization is just 8% across 23,000+ production clusters, which means most clusters have substantial, measurable waste waiting to be surfaced.