What usage window are recommendations based on?

Container requests use 7 days of per-pod usage at p95; node groups use 14 days of peak hourly requests. Review workloads whose busiest days fall outside those windows before approving.

Do we need Prometheus?

No. Without Prometheus, KubeOn uses the hourly samples the agent reads from metrics-server. Prometheus adds hourly history and the volume usage that over-provisioned volume findings need.

With the same rule as CPU: p95 plus 20%, never below 0.25 GB. Because a container above its memory limit is killed, compare the proposal with the workload's highest memory use, its limit and its restart history first.

Kubernetes rightsizing

Requests and nodes sized from what workloads use

KubeOn sizes container requests from p95 usage and node groups from peak requests, prices each change with your billed rates, and delivers it as a reviewable patch.

Book a demo Platform overview

Savings

Right-size requests · Workload

Right-size requestsLow risk

Right-size requests: checkout-api

Lower CPU requests on checkout-api from 2 cores to 0.6 per pod and memory from 4 GiB to 2.5 GiB, across 6 replicas. Estimated saving $412.80 a month ($4,953.60 a year).

Cost now

$589.71

per month, run rate

After the change

$176.91

per month

Monthly saving

$412.80

6 replicas

Annual saving

$4,953.60

at today's run rate

Cluster: prod-use1-a
Namespace: checkout
Workload: checkout-api
Replicas: 6
CPU request: 2 → 0.6 cores
Memory request: 4 → 2.5 GiB
p95 CPU, 7 days: 0.50 cores
p95 memory, 7 days: 2.08 GiB

Rollout

Opens as a pull request on the workload's own values file.
After merge, KubeOn watches restarts and memory for 24 hours.

Risks to check

Limits are unchanged; a pod above its memory request is evicted first under pressure.

How KubeOn worked this out

p95 of 7 days of hourly samples plus 20% headroom, rounded up to the next 100m of CPU and 256 MiB of memory.

What UnitVane brings to this job

Monthly savings, each with the rule that found it

Savings

Container requests are sized from p95 usage over 7 days, node groups from 14 days of peak requests. Orphaned volumes, abandoned workloads and off-hours schedules are priced per month and recomputed every 30 minutes.

Explore Savings

Savings

Data readyUpdated 12 min ago

Last 7 days▾

Savings

Opportunities derived from measured usage. Select a card to filter the recommendations.

Savings available

$21,842.17/mo

$262,106.04 a year

Computed 12 min ago; refreshed every 30 minutes.

Up to $1,240.00/mo more in possible orphans, kept out of the total until someone checks them.

Where it comes from

Compute plan $20.1KStorage and unused workloads $1.79K

Right-size requests

$8,412.50

Consolidate nodes

$7,930.20

Abandoned workloads

$3,108.75

Delete orphaned volumes

$1,584.32

Pause outside working hours

$605.13

Reclaim released volumes

$201.27

Detailed recommendations

1,284 total

Resource	Scope	Issue	Current	Recommended	Savings
generalprod-use1-a	prod-use1-a	Consolidate nodes	12 × m7i.4xlarge	16 × m7i.2xlarge	$3,184.40/mo
memoryprod-euw1-a	prod-euw1-a	Consolidate nodes	8 × r7i.2xlarge	6 × m7i.2xlarge	$1,702.15/mo
catalogdev-use2	dev-use2	Pause outside working hours	24 × 7	Weekdays 07:00–20:00	$605.13/mo
search-indexerprod-euw1-a / search	prod-euw1-a / search	Right-size requests	8 GiB per pod	3.2 GiB per pod	$488.10/mo
checkout-apiprod-use1-a / checkout	prod-use1-a / checkout	Right-size requests	2 cores per pod	0.6 cores per pod	$412.80/mo

Reviewable changes, shipped the way you choose

Change proposals

Every saving worth $25 or more a month becomes a proposal with current and proposed state, evidence, a risk level and a ready-to-apply patch. Ship it as a pull request, or let KubeOn apply it where you granted write access.

Explore Change proposals

Proposals

Right-size checkout-api requests in prod-use1-a

ProposedLow riskRight-size requests · prod-use1-a / checkout

$412.80/month

CPU requests are 4× the p95 usage across 6 replicas. Lowering them to 600m frees about 8.4 vCPU on the general node pool.Summary generated from the measurements below

Now

CPU per pod: 2 cores
Memory per pod: 4 GiB
Replicas: 6

Proposed

CPU per pod: 0.6 cores
Memory per pod: 2.5 GiB
Replicas: 6

Evidence

CPU: p95 0.50 cores per pod over 7 days of hourly samples, 25% of the request.
Memory: p95 2.08 GiB per pod; the highest hourly sample was 2.31 GiB.

Change to apply Copy

# charts/checkout/values-prod.yaml
checkout-api:
  resources:
    requests:
      cpu: 600m        # was 2
      memory: 2560Mi   # was 4Gi

On approval, KubeOn opens a pull request on acme/platform-config. Your CD deploys it; production always waits for a person to merge.

RejectApprove

The problem

Why it is hard today

Requests and nodes sized from measured usage

Averages hide the peak:
Sizing from average usage breaks the busiest hour of the week.
Savings without a price:
A recommendation in millicores does not tell anyone what it is worth.
No safe way to apply it:
Changes outside Git are reverted by the next deploy or blocked by review.

How UnitVane handles it

What you get

p95 over 7 days

Per pod, with 20% headroom and floors for small services.

Peak-based node sizing

14 days of peak hourly requests with 20% headroom.

Priced per month

With your billed node rates, not list prices.

Patches

YAML requests and Karpenter NodePool changes.

Off-hours schedules

Dev and test namespaces scaled down at night.

Risk levels

Low, medium or high per change, with rollout steps.

Outcomes

What changes for your team

Changes engineers accept

The evidence and the patch arrive together.

A ranked list by monthly saving

High above $100 a month, medium above $10.

Your first weeks

What you see, and when

From the first agent run to findings that need a full usage history.

01
Within the first hour
The cluster, its nodes, namespaces and workloads appear in Diagnostics. Allocated cost per namespace, team and label follows as soon as billing data is in.
02
Once billing data is in
180 days of history are read and allocated, plus 30 days of per-pod split cost history where AWS split cost allocation data exists. A brand-new AWS export can take up to a day to deliver its first file. The allocated history is kept; the raw billing rows leave the hub after 90 days.
03
Within 30 minutes of the first allocation
Savings are computed, starting with findings that need no usage history, such as released volumes that still bill. Change proposals follow at the next daily regeneration.
04
After 7 days of usage
Container requests are right-sized from p95 usage over 7 days of hourly samples.
05
After 14 days
Node group sizing and abandoned workloads, which each need 14 days of data, and over-provisioned volumes, which also need Prometheus volume usage.

UnitVane works with your technology

Every major cloud, any Kubernetes, and the tools and model providers your teams already use.

All integrations

AWS

Microsoft Azure

Google Cloud

Cloud

Kubernetes

Red Hat OpenShift

Rancher

Tanzu

k3s

Helm

Terraform

Argo CD

Flux

Prometheus

OpenTelemetry

Okta

Slack

Microsoft Teams

OpenAI

Anthropic

Mistral AI

Your questions answered

Keep reading

Expert guides and related solutions

Article

Rightsizing requests with p95, headroom and a floor

Over-sized requests are the most common cause of Kubernetes overspend. Averages break the busiest hour and maximums waste money every other hour. A sizing rule engineers will accept, and what it cannot see.

Article

Why cost recommendations don't get shipped

Most cost tools find savings. Few savings reach production. What engineers need before they change a running service, and what changes when a saving arrives as a reviewed patch instead of a dashboard row.

Solution by use case

Showback and chargeback

A bill for every team, idle and shared included

Solution by use case

Idle and waste cleanup

Abandoned workloads and orphaned volumes, found and priced

Solution by use case

Budgets and anomalies

Forecasts and spikes, sent to the owner

All resources

Ready to see it on your own data?

A 30-minute walkthrough on your own billing data, for your clouds, your clusters and your model providers.

Book a demo Plan an evaluation

Requests and nodes sized from what workloads use

What UnitVane brings to this job

Savings

Change proposals

Why it is hard today

Averages hide the peak:

Savings without a price:

No safe way to apply it:

What you get

p95 over 7 days

Peak-based node sizing

Priced per month

Patches

Off-hours schedules

Risk levels

What changes for your team

Changes engineers accept

A ranked list by monthly saving

What you see, and when

Within the first hour

Once billing data is in

Within 30 minutes of the first allocation

After 7 days of usage

After 14 days

Your questions answered

What usage window are recommendations based on?

Do we need Prometheus?

How is memory sized?

Expert guides and related solutions

Ready to see it on your own data?