Calculator
The Kubernetes Waste Analyzer
Paste your cluster's own kubectl output. It never leaves this browser. See requests broken down by namespace and workload, workload idle against measured usage once you add kubectl top, and nine findings, each linked to a fix.
Last updated
This is a static site with no backend to upload to. Parsing and analysis all happen in your browser's JavaScript. Check the Network tab while you paste a file in and you'll see nothing sent anywhere.
This result is not saved. It disappears when you reload the page. Copy it as Markdown or download it before you leave.
Free tool
Paste your cluster's own kubectl output
Only kubectl get pods -A -o json is required. Add measured usage (kubectl top or the metrics API) to unlock a dollar figure, and a node list on top of that to split out cluster idle. Everything below computes in your browser; nothing you paste in is sent anywhere.
kubectl get pods -A -o json — parsed entirely in your browser
Prefer a smaller paste? Strip the pod file down to only what this tool reads first:
kubectl get pods -A -o json | jq '{kind:"PodList",items:[.items[]|{metadata:{name,namespace,ownerReferences},spec:{containers:[.spec.containers[]|{name,resources}],initContainers:[(.spec.initContainers//[])[]|{name,resources,restartPolicy}],overhead:.spec.overhead},status:{phase:.status.phase}}]}'Unlocks a dollar figure and the usage-based findings.
Unlocks the cluster-idle split, on top of usage data.
The number already on your bill for this cluster.
The cost-unit equivalence used to compare CPU and memory in dollars.
Reading your file…
By namespace
By workload
What to look at
This is a static site with no backend to upload to — parsing and analysis run entirely in your browser's JavaScript. Check the Network tab while you use this tool and you'll see nothing sent anywhere.
How to get these files
Only the pod list is required. Here's exactly how to get each input, and what adding it unlocks.
Pod manifests (required)
kubectl get pods -A -o json
Per-namespace and per-workload request roll-up, plus every structural finding
- Run the command. Run kubectl get pods -A -o json against the cluster you want analyzed. Read access to pods is all this needs.
- Prefer a smaller file? Strip it first. The jq one-liner below trims the output to just namespace, name, ownership, container resources, and phase, the exact fields this tool reads, before anything touches your clipboard.
- Paste it in below. Drop the file onto the drop zone, or paste its contents into the text box. Nothing is uploaded anywhere; open your browser's Network tab and watch for yourself.
Source: Kubernetes docs: Resource Management for Pods and Containers
Measured usage (kubectl top) (optional)
kubectl top pods -A --containers
A dollar figure, and every usage-based finding: oversized requests, idle workloads, under-requested pods
- Install metrics-server. kubectl top needs the metrics-server add-on running in-cluster. Most managed clusters (EKS, GKE, AKS) already have it.
- Run the command. kubectl top pods -A --containers prints one line per container. Paste the whole thing, including its header row.
- Remember it's one sample. This is a snapshot, not an average. See the caveat below before trimming anything based on it.
Measured usage (metrics API) (optional)
kubectl get --raw /apis/metrics.k8s.io/v1beta1/pods
The same dollar figure and usage-based findings as kubectl top, from the raw JSON instead of the formatted text
- Run the command. kubectl get --raw /apis/metrics.k8s.io/v1beta1/pods returns the same metrics-server data kubectl top reads, as a PodMetricsList JSON document.
- Paste either format, not both. This tool reads either kubectl top's plain text or this JSON. Pick whichever you already have; there's no need to fetch both.
Node capacity (optional)
kubectl get nodes -o json
The cluster-idle bucket: allocatable capacity nobody requested, split out from workload idle
- Run the command. kubectl get nodes -o json lists every node's allocatable CPU and memory, the capacity actually schedulable after the kubelet and OS take their share.
- Skip it if you'd rather not. Without this file the tool still reports workload idle against requests, just not the cluster-idle split, and says so plainly.
Source: Kubernetes docs: Resource Management for Pods and Containers
How the dollar figure works
The money input is the monthly node/compute bill you already have for this cluster, so there's no instance-rate table to maintain or misquote. CPU and memory become one comparable "cost unit" using a 1 vCPU ≈ 4 GiB equivalence (the ratio behind general-purpose instance families: AWS's m-family, GCP's n2-standard, Azure's Dv5), and that ratio is an editable field above the results, not a fixed constant.
Two honest caveats worth reading before acting on any number this tool prints. First, trimming a request only turns into money once the cluster's actual node count falls, or the autoscaler scales in; a smaller request that leaves every node just as full changes nothing about the bill. Second, both kubectl top and the metrics API report a single instantaneous sample, not a historical average; sizing a request down to one low reading risks an OOM kill or CPU throttling the next time load is even slightly higher. Sample over a few days before trusting a right-sizing number.
What we look for
Nine finding rules, each computed from your own manifests and measurements. Nothing here is a guaranteed saving; it's what to check next, and each one links to a fix.
- Some containers request no CPU, no memory, or neither. Without a request, the scheduler has nothing to reserve on a container's behalf, so it lands wherever there's room and competes for whatever's left, whether that's abundant or already gone. Setting a request is the first fix on the checklist below, and it costs nothing on its own.
- Some containers set a CPU limit. A CPU limit is a hard ceiling the kernel enforces with CFS throttling, and a container gets throttled the moment it touches that ceiling, even if the node around it is otherwise idle. Most guidance now recommends a CPU request with no CPU limit, and a memory limit without exception. Worth checking whether these limits were a deliberate call or copied from a template.
- Some containers request memory with no memory limit set. A memory limit is what stands between one leaking container and the node's other pods: without it, that single container can be OOM-killed at any point once the node runs out, taking a somewhat arbitrary victim with it. Unlike a CPU limit, a memory limit costs nothing in throttling risk and is worth setting on every container that has a request.
- Some workloads use far less CPU than they request. Every millicore requested but unused is still capacity the scheduler set aside, and it's what actually determines how many nodes this cluster needs. Pull a few days of usage, not just this one sample, and bring the request down to what's actually used plus a margin.
- Some workloads use far less memory than they request. Memory headroom feels safer to over-provision than CPU, but the gap between requested and used is priced the same either way. A Vertical Pod Autoscaler can turn a few days of this same measurement into a recommendation automatically, rather than a one-off manual pass.
- Some workloads are barely doing anything on either resource. A workload idling on both CPU and memory at once is the clearest case for right-sizing, or for asking whether it needs to run at this size, on this schedule, at all. Check it against what the workload is actually for before assuming the fix is purely a smaller request.
- Some workloads measured usage at or above their own request. This is the one finding here that isn't about spending less: a pod using more than it requested is a pod one bad moment away from CPU throttling or an OOM kill, and the fix is raising the request, not lowering it. Worth checking before this shows up as an incident instead of a line on this page.
- One namespace holds most of what this cluster requests. That's not automatically a problem on a cluster with one dominant service, but it is the single highest-leverage place to check request sizing first, since a change there moves more of the bill than anywhere else in this file.
- A small per-replica gap adds up once it's multiplied across replicas. A request that's only modestly oversized on a single pod is easy to overlook. The same gap times a real replica count is usually where the actual money is on a cluster like this one, ahead of any single pod's own number.
Sources
Where the parsing rules and the stats on this page come from
The quantity formats, the sidecar-accounting rule, and the single-sample caveat above are attributed to Kubernetes' own documentation, current as of 2026-08-14.
- Kubernetes — Resource Management for Pods and Containers
Defines the CPU (m) and memory (Ki/Mi/Gi/Ti binary, k/M/G/T decimal) quantity suffixes this tool's parser follows, and states that CPU limits are enforced by hard kernel throttling while memory limits are enforced reactively via OOM kill. That's the basis for the cpu-limit-throttling and no-memory-limit findings.
- Kubernetes — Sidecar Containers
States the exact effective-request formula this tool implements: "the Pod's effective request/limit for a resource is the sum of pod overhead and the higher of: the sum of all non-init containers (app and sidecar containers) request/limit for a resource, [or] the effective init request/limit," where the effective init request/limit is the highest single request among all init containers, sidecars included.
- Kubernetes — Resource metrics pipeline
Documents that both kubectl top and the metrics.k8s.io API report an instantaneous sample over a short window (the API's own `window` field), not a historical average. That's the basis for this tool's single-sample caveat.
- Datadog — State of Cloud Costs
Analyzing cloud cost data from organizations using Datadog Cloud Cost Management between May 2023 and April 2024: "83 percent of container costs are associated with idle resources," split 54 points cluster idle and 29 points workload idle. This tool's cost model uses that same two-bucket split once node data is supplied. The page states no explicit publication date, so the May 2023 to April 2024 data window is quoted here instead of one.
- CAST AI — 2026 State of Kubernetes Optimization Report
Vendor telemetry from tens of thousands of clusters across AWS, Azure, and GCP, covering 2025 through April 2026, collected before any of CAST AI's own automation ran: average CPU utilization 8%, memory 20%, GPU 5%; CPU overprovisioning 69%, memory 79%. No exact publication date is stated on the page, and the sample is limited to organizations already on CAST AI's platform, so it's cited here as vendor telemetry, not an industry-wide baseline.
FAQ
Common questions about the Kubernetes Waste Analyzer
Is anything I paste into this tool uploaded anywhere?
No. CostMon's marketing site is a static build with no backend to upload to. Whatever you paste in is parsed and analyzed entirely in your browser's JavaScript. Open your browser's Network tab while you use the tool and you'll see no request carrying your data, because there isn't one.
Do I have to bring all three optional files?
No, only kubectl get pods -A -o json is required. Adding kubectl top or the metrics API output unlocks a dollar figure and the usage-based findings; adding a node list on top of that also splits out cluster idle from workload idle. Bring whichever you have.
Why is there no dollar figure when I only paste in the pod file?
Because a request is a reservation, not a measurement. Without usage data this tool has no way to know how much of that reservation is actually used, so it shows the request breakdown and the structural findings, and says plainly that a dollar figure needs kubectl top or the metrics API.
Is kubectl top's number the same as a week's average usage?
No, and this matters: both kubectl top and the metrics API report an instantaneous sample, not a historical average. Sizing a request down to one low sample risks an OOM kill or CPU throttling the next time load is even slightly higher. Sample over a few days, at different times, before trusting a right-sizing number this tool suggests.
If this tool says a workload is oversized, does trimming its request actually save money?
Only if the node count this cluster runs actually falls afterward, or the autoscaler scales in. A smaller request that still leaves every node just as full changes nothing about the bill; it only pays off once fewer nodes are needed to hold everything that's still requested.
How does the workload roll-up figure out a Deployment or CronJob's name?
It's a heuristic, not something read from the API: a pod owned by a ReplicaSet whose name ends in what looks like a pod-template-hash gets that suffix stripped to recover the Deployment name, and the same idea applies to a Job's trailing timestamp segment to recover a CronJob's name. A hand-created ReplicaSet or Job with a similarly-shaped name strips the same way and can't be told apart from the generated case.
What's the 1 vCPU ≈ 4 GiB assumption for, and can I change it?
CPU and memory are different units, so dollarizing a mixed CPU/memory gap needs some equivalence between them. This tool uses the ratio behind general-purpose instance families (AWS's m-family, GCP's n2-standard, Azure's Dv5), and the field above the results is editable if your cluster runs mostly memory- or compute-optimized nodes instead.
Does this replace kubernetes-costs, CostMon's other Kubernetes calculator?
No, they answer different questions. Kubernetes Costs is a typed slider model: move a utilization percentage and see what a cluster shaped like that would split into. This tool reads your actual manifests and measured usage instead of a percentage you type in. Cross-check one against the other; they shouldn't tell wildly different stories about the same cluster.
Does this tool run anything inside my cluster?
No. It only reads text you already exported with kubectl and pasted in yourself; it has no cluster access, no service account, and no in-cluster component of any kind. Tools like Kubecost, OpenCost, Robusta KRR, or Goldilocks do run in-cluster and can watch continuously, which this static page deliberately doesn't try to replace.
A bill read by hand goes stale tomorrow.
Reading one export line by line takes real work. CostMon reads the next one for you, every day, for every provider you connect.