Savings methodology
The rule behind every saving, with the windows, thresholds and headroom KubeOn uses.
All savings are monthly: each cluster's window is scaled to 30 days. Totals are recomputed every 30 minutes. Priority is high above $100 a month, medium above $10, and low otherwise.
Container requests
- Window: 7 days of per-pod usage, from Prometheus if configured, otherwise the agent's samples.
- Statistic: p95 per pod, or the mean if it is higher.
- Flag: utilization under 30% of the request.
- Recommendation: max(p95 x 1.2, 0.025 cores) for CPU and max(p95 x 1.2, 0.25 GB) for memory.
- Workloads at 2% of request or less are reported as abandoned instead.
Node groups
- Window: 14 days of peak hourly scheduled requests per node, with 20% headroom.
- Smaller nodes: when 40% or more of both CPU and memory is spare. Saving: node cost times the smaller spare share.
- Family change: when 50% or more of one resource is spare. Saving is capped at the typical price gap of one family step.
- Findings under $1 a month are dropped.
Storage
| Finding | Rule |
|---|---|
| Orphaned volume | Billing 24 hours or more after its PV disappeared, from a cluster that is still reporting, and at least $0.50 over 7 days |
| Released volume | PV in Released, Available or Failed with a backing volume still billing $0.50 or more a month |
| Over-provisioned volume | At least 24 hourly samples over 14 days; recommends max(peak x 1.5, 1 GiB) when 30% or more is reclaimable |
| Orphaned file system volumes | Released PVs grouped by file system; cost estimated as an even share of the file system |
| Older storage class | AWS gp2 volumes priced at the gp3 rate for the same size. Volumes over 170 GiB can get more throughput on gp2 than gp3's 125 MiB/s baseline, so they are flagged for review and not counted |
| Possible orphans | Billed daily for 7 days with no PV and no cluster tag, in non-production accounts; an upper bound, excluded from the headline |
Off-hours schedules
For dev, test, QA and sandbox clusters, namespaces costing $200 or more a month get a schedule proposal. The estimate assumes 103 idle hours a week (outside 07:00 to 20:00 on weekdays) and 70% of the namespace being scalable.
Evidence and limits
Every finding rests on a stated window and statistic. Read them together with what the measurements cannot show.
| Question | Answer |
|---|---|
| How often is usage measured? | Once an hour. Each agent run records every pod's current usage from metrics-server, so a 7-day window holds up to 168 samples per pod. With Prometheus connected, KubeOn reads an hourly series from it instead. |
| Can a short spike be missed? | Yes. A burst shorter than an hour can fall between samples. The 20% headroom and the 30% flag leave a margin, but for bursty or latency-sensitive workloads, check limits, autoscaler settings and restart history before approving. |
| How is memory sized? | With the same rule as CPU: p95 plus 20%, never below 0.25 GB. Memory is not throttled the way CPU is: a pod above its memory request is the first to be evicted when its node runs short, and a container above its limit is killed. Before approving, compare the proposed value with the workload's highest memory use, its limit and its restart history. |
| What about monthly or seasonal peaks? | Container requests use a 7-day window and node groups 14 days. Neither sees a month-end batch or a seasonal peak, so reject proposals for workloads whose peaks fall outside the window. |
| What does the rule leave out? | Container rightsizing uses requests and measured usage only. CPU throttling, out-of-memory restarts and how critical a workload is are for the reviewer to weigh. |
| How risky is a proposal? | Each proposal has a risk level of low, medium or high, computed per kind of change, with its risks and safe rollout steps. An optional summary written from the evidence can raise the risk, never lower it. |
| Is the saving guaranteed? | No. Savings are monthly estimates at your billed prices. A lower request moves cost from the workload to idle until nodes scale down or pack tighter, so the saving is realized when the node bill falls. Compare the cluster's bill before and after the change. |
| Who applies the change? | You choose per cluster: merge the pull request through your pipeline, or let the controller apply it where you granted write access. Proposals the data no longer supports become superseded. |
Need help with this guide?Contact support