Efficiency Scoring

CostPilot’s efficiency score gives you a single number that represents how well your cluster resources are being used. This page explains the calculation, the grading system, and practical strategies for improving your score.

What efficiency measures

Efficiency measures the ratio of actual resource usage to resource requests across your cluster, weighted by cost.

A pod that requests 1 CPU and uses 1 CPU is 100% efficient. A pod that requests 1 CPU and uses 0.1 CPU is 10% efficient. CostPilot aggregates this across all pods, weighting each pod by its allocated cost.

High efficiency means your resource requests are well-tuned to actual workload behaviour — you’re not paying for unused capacity.

Low efficiency doesn’t necessarily mean waste from the cluster’s perspective (the node may still be fully utilised by other pods), but it does mean your cost attribution model isn’t accurate and there’s likely overprovisioning to address.

The calculation

Efficiency is calculated separately for CPU and memory, then combined:

CPU efficiency    = actual CPU usage  ÷ CPU requests
Memory efficiency = actual memory usage ÷ memory requests
Overall efficiency = (CPU efficiency + memory efficiency) ÷ 2

Each pod’s efficiency is weighted by its allocated cost when computing the cluster-wide average. This means expensive, inefficient pods pull the score down more than cheap ones.

The grading system

CostPilot converts efficiency percentages to letter grades:

Grade	Efficiency range	Interpretation
A	90–100%	Excellent — very tight resource management
B	75–89%	Good — well-tuned with appropriate headroom
C	60–74%	Fair — noticeable optimisation opportunities
D	45–59%	Poor — significant overprovisioning present
E	30–44%	Very poor — major waste across many workloads
F	0–29%	Critical — resource requests need immediate review

What grade should I target?

For most production clusters, a B grade (75–89%) is the right target. This reflects:

• Workloads tuned to their typical usage
• Sufficient headroom for traffic spikes (10–25% buffer above typical usage)
• Not so tight that workloads risk OOMKills or CPU throttling during peaks

An A grade is possible but typically requires aggressive autoscaling and very stable workload profiles. For most teams, the risk of incidents from under-provisioned headroom outweighs the marginal cost savings of moving from B to A.

An F grade warrants immediate attention — it usually indicates default resource requests that were never tuned, or a cluster that’s significantly over-provisioned for its current workload.

Where efficiency is shown

Efficiency scores appear throughout CostPilot:

• Dashboard — Cluster-wide efficiency score in the summary bar
• Cost Explorer — Per-namespace, per-workload, and per-label efficiency columns
• Insights — The Basic and Advanced Efficiency analysers flag specific workloads with low scores and quantify the savings from right-sizing

Improving your efficiency score

1. Identify the lowest-efficiency workloads

In Cost Explorer, select the Workload dimension and sort by Efficiency ascending. The top results are your biggest opportunity — focus on the ones with the highest cost × lowest efficiency, as these have the largest savings potential.

2. Right-size resource requests

For each low-efficiency workload, look at actual CPU and memory usage over the past 7–30 days. Set requests to approximately the 90th percentile of observed usage, plus 10–20% buffer:

new_cpu_request    = p90_cpu_usage × 1.15
new_memory_request = p90_memory_usage × 1.20

CostPilot’s Insights will suggest specific values where it has enough data.

3. Use Vertical Pod Autoscaler

VPA in Off or Initial mode generates request recommendations without automatically changing your deployments. This is a safe starting point that gives you data-driven suggestions you can review and apply manually.

4. Review defaults in your deployment templates

If your organisation has a Helm chart template or Kubernetes deployment template with default resource requests, review those defaults. A single template change can right-size hundreds of workloads at once.

5. Set up regular reviews

Efficiency naturally degrades over time as codebases grow and workloads change but resource requests don’t. A quarterly review of the lowest-efficiency namespaces keeps the score from drifting.