How Onicost computes a request
Onicost works container by container, over a window of 14 days by default, between 7 and 30. For CPU, it takes the 95th percentile of per-minute usage and adds a 15% margin. For memory, it takes the peak of the window and adds 20%. The difference comes from Kubernetes: a CPU limit throttles the container, while a memory limit can get it killed.
A request drops only when the current value exceeds the recommended one by more than 20%. This threshold filters out small gains that do not justify a deployment. A request rises as soon as the percentile or the peak passes it.
These values are settings. You can choose p90, p95 or p99, change the margins and add up to 20 namespace policies. The first match wins, so production can aim for p99 while development stays at p90. A policy can also exclude a namespace from every family of recommendations except Nodes.
How far to trust a recommendation
Each recommendation carries a score from 0 to 100: days of data for 40 points, stability for 25, bursts for 15, health for 10 and seasonality for 10. It reads low under 40 and medium under 70. Before 3 days of data, the rules on requests stay silent. From 3 to 7 days, a recommendation stays provisional: it can still be withdrawn, and its savings stay out of the total.
The detail page sets the evidence next to the numbers: CPU percentiles from p50 to p99, memory peaks, OOM kills, throttled CPU periods, restarts and replica changes. Agents before version 0.6.0 send no peaks, OOM kills or throttling. Onicost then treats these signals as unknown and never counts them as zero.
Guardrails built into the rules
A lower bill paid for with an incident is no saving. Several rules therefore protect your services. The HPA is a good example: it computes utilization as a percentage of the request, so a lower request can change how it behaves.
- After an OOM kill in the window, the memory request does not go down. A peak above it pushes it up.
- Under an HPA on CPU utilization, the CPU request stays at least where the percentile meets the HPA target.
- A recommended request above the current limit raises that limit too, since Kubernetes would refuse the request.
- The rules Requests too low, Container killed out of memory and CPU throttled push values up, with no savings shown.
- A zombie workload leaves the list of requests to review: the right question is then whether to stop it.
From a request to the bill
A lower request frees capacity. The bill moves when a node leaves. Onicost therefore states the basis of each saving. Bill means the catalog price of the nodes or the volume. Allocation means the allocated cost of the requests, which lowers the bill only once nodes are freed. Estimated rests on an assumption.
Onicost then replays the placement of each pool with every rightsizing applied, up to 80% fill by default. It shows the share realizable by freeing nodes. On Fargate, GKE Autopilot and AKS virtual nodes, a smaller size can reach the bill directly, since the provider bills the pod. The gap has to reach at least one billing step.
After the change, Onicost detects it and measures the pool: daily cost over the 7 days after the change against the 7 days before, brought to 30.4 days. It can also report that no node was freed.
Apply the change, or let the auto-resize do it
Each recommendation gives current and recommended values. The recommended YAML goes into your manifest or Helm values. On Kubernetes 1.35 and later, the auto-resize applies the CPU then memory requests itself, by 20% at most per night, in each namespace whose switch stays on, and rolls back at the first OOM or throttling. The other recommendations stay with your team. The scheduler, for its part, stops and restarts workloads without touching their requests.
The Vertical Pod Autoscaler takes another route. In Off mode, it stores its recommendations in the status of the VPA object. In Initial mode, it sets requests when pods are created. Other modes update pods. If VPA manages a workload, keep one source of truth for its requests. Onicost adds the cost, the node view and the follow-up.
What each plan shows
Free shows every recommendation, with the values to apply by hand, and the simulation of the auto-resize, workload by workload. Team, from €39 per month before tax, turns on the auto-resize and the Scheduler, with a free 14-day trial. Displayed savings are estimates, and none is guaranteed.
Frequently asked questions
Does Onicost apply rightsizing for me?
For requests, yes if you turn it on: on Kubernetes 1.35 and later, the auto-resize lowers them in small steps in each namespace whose switch stays on, and rolls back at the first incident. Otherwise, it gives the values and the YAML, and your team applies them with its own tools.
How long before I get a recommendation?
The rules on requests speak from 3 days of data, as provisional, and confirm at 7 days. A BestEffort pod is flagged from the first inventory.
Why a percentile for CPU and a peak for memory?
CPU that runs short slows the container down. Memory that runs short can kill it. Onicost therefore accepts rare CPU overruns and covers the memory peak.