Skip to main content
Rightsizing compares configured CPU and memory requests with recent observed demand. You can scan the workloads visible in your current namespace selection, or inspect one workload from its detail page.
Rightsizing is an advisory snapshot. It is not a guaranteed savings estimate, a capacity plan, or an automatic change.

​
Scan visible workloads

Open Cost → Rightsizing and start a scan when you want to review request sizing across the current view. Radar includes the Deployments, StatefulSets, and DaemonSets that you are allowed to see in the selected namespaces. Rightsizing uses Prometheus independently of the OpenCost-backed Overview tab. The default worklist focuses on three actions:
  • Increase or add - a request is missing or recent demand exceeds it.
  • Reduce requests - a meaningful amount of requested capacity could be reclaimed.
  • Review first - an HPA, runtime signal, or lack of current replicas means the evidence needs manual context.
Containers with no meaningful change and containers without enough data are available separately. Kubernetes system workloads are hidden by default because they are often managed by the cluster provider; include them when you are reviewing platform overhead. Each row represents one workload container and states the suggested action for CPU and memory. The capacity change is multiplied by the workload’s desired replicas so small per-pod differences do not rank alongside larger opportunities without context. Expand a row for a plain-language explanation, or open the workload to investigate its history. Workloads with no current replicas remain visible, but Radar does not present their retained history as an action to take now. Review them before replicas run again. The scan runs only when you start it. A broad selection can take longer, and Radar may return a partial result if some bounded batches cannot complete. Partial results remain usable and clearly identify missing coverage.

​
Evidence and methodology

Radar analyzes the last seven days in 5-minute samples:
  • CPU - P95 observed usage plus 15% headroom.
  • Memory - maximum observed working set plus 15% headroom.
  • Ownership - kube-state-metrics ownership for fleet scans. A single-workload view can fall back to exact current pods.
  • Restart safety - memory reductions require verifiable restart and termination-reason history for the same seven-day window.
  • Evidence quality - reflects history coverage and ownership quality. Radar shows the underlying evidence instead of reducing it to an efficiency score.
The view keeps CPU and memory separate because they can point in different directions and have different operating risks. Radar rounds recommendations to practical Kubernetes values: finer steps for small requests and wider steps as requests grow. For reductions, Radar separates the demand-based target from the suggested next step. It will not suggest cutting memory or a CPU request of at least one core by more than half in one review window. Smaller CPU requests are also protected by staged reduction floors, and every CPU recommendation keeps at least 10m. Memory keeps at least 64Mi. Recommendations are rounded with wider steps at larger scales. Observe another full window before reducing further.

​
Safety signals

Radar routes a row to Review first or withholds the affected suggestion when:
  • an HPA manages that resource;
  • HPA status cannot be determined for a potential reduction;
  • a lower memory request conflicts with OOM evidence, or restart history cannot rule it out;
  • the suggestion would exceed the current limit;
  • CPU usage is bursty or limit throttling was observed;
  • the workload has no current replicas;
  • history is insufficient; or
  • a required Prometheus query failed.
Throttling and OOM badges are runtime evidence, not part of a combined efficiency score.

​
How to use it

Use Rightsizing to find workloads worth investigating, then review each workload in context. Capacity changes are requested resources across replicas, not guaranteed reductions in your cloud bill. Before changing requests, consider expected traffic changes, startup behavior, SLOs, autoscaling policy, and load-test results. Radar does not apply YAML changes or estimate guaranteed cost savings. The methodology is inspired by open source tools such as Kubernetes Resource Recommender, while keeping recommendations inside Radar’s existing Prometheus and workload views.

​
Data requirements

Rightsizing requires container usage metrics from Prometheus. Fleet scans also require kube-state-metrics ownership, HPA, restart-counter, and termination-reason series so historical samples can be attributed and safety checks can be evaluated. Missing safety evidence withholds the affected reduction rather than treating the signal as clean. If historical ownership data is unavailable, use the workload detail view for current-pod evidence.

​
See also