Walking the floor at KubeCon Amsterdam, I kept having the same conversation - different company, different stack, same frustration. On average, over 70% of Kubernetes spend turns out to be waste. Everyone knew it. Almost nobody had a clean way to fix it.
What surprised me wasn't that people didn't understand the problem - they did, often in impressive detail. What surprised me was how stuck everyone felt anyway.
Platform engineers who knew there was a waste, but weren’t sure where it was. Developers who'd never seen a utilization number for their own workloads. The knowledge existed. The visibility didn't.
The visibility gap is what keeps waste from actually getting fixed. Across the organizations we work with, on average, over 70% of Kubernetes spend turns out to be waste once you start measuring it properly. The number is almost always surprising, even to the people who suspected it was bad.
The framework most teams already have in their heads is the right one. There are two fundamentally different waste types, which live at different layers of the stack, with different owners and fixes.
The first is node-level idle: capacity on a node that isn't allocated to any running pod. The node is running, you're paying for it, but a portion of its CPU and memory is unassigned, typically the result of oversized instances or autoscaling that hasn't caught up to lower demand. This one falls squarely on the infra and platform teams.
The second is workload-level over-provisioning: the pod is running and the resources are allocated, but actual usage is a fraction of what was requested. This one belongs to developers.
If you roll both into a single "Kubernetes idle" number, you end up with a metric nobody owns — and a metric nobody owns is a metric nobody fixes. Infra teams say it's a developer problem. Developers say they're just following cluster defaults. Nothing changes.
Node-level idle is relatively straightforward to measure: you know the node cost from your cloud bill, you know which pods are running on it, and the gap is your idle cost. The math is clear.
Workload-level waste is trickier. To know that a workload is over-provisioned, you need to compare what was requested against what was actually used - at the pod level, across time, with enough granularity to be actionable. In addition, most observability tools don't surface this at all.
The right approach is to look at each pod's CPU and memory allocation compared to its actual runtime consumption, hour by hour. When requests consistently exceed usage, you've found a candidate for rightsizing.
The formula isn't complicated - what's hard is collecting enough samples across time, since usage varies minute to minute, and aggregating them correctly so the signal is meaningful rather than noisy. Get that wrong, and your waste numbers are either inflated or missed entirely. Get it right, and then you still need to surface the output to the people who can act on it.
Finout already provides a solution for what people asked in KubeCon!
For node-level idle, the goal is simple: stop paying for capacity nobody claimed. To support this, Finout surfaces it as a dedicated idle namespace dimension. Using it, Infra teams can easily see it in Megabill, set anomaly alerts, build widgets, and use Virtual Tags to assign it to the relevant team - creating accountability without manual slicing.
For workload-level waste, the goal is getting rightsizing decisions in front of the people who can act on them. Finout calculates over-provisioning at the pod level and surfaces it via the Kubernetes Utilization Type dimension - which breaks down K8s spend into idle nodes and both utilized and unutilized pod costs, directly in the MegaBill, not buried in a separate dashboard. Virtual Tags let you allocate that waste to the team that owns the workload, and CostGuard scans proactively to flag over-provisioned workloads with rightsizing recommendations.
The interest I saw at KubeCon wasn't curiosity — it was frustration looking for a solution. Coming back from Amsterdam, what stayed with me was how closely the problems people described mapped to what we'd already built. Every gap they articulated, Finout already addresses. Detecting K8s underutilization is a real challenge — but when you get it right, the savings potential is significant.