Skip to main content

Overview

Rightsizing analyzes the gap between what each workload has reserved (resource requests) and what it’s actually using (observed metrics). It surfaces workloads that are over-requested — wasting reserved capacity — and workloads that are under-requested — at risk of throttling or eviction. Recommendations are advisory and visible to all plans. Applying them via pull request requires Pro.

Prerequisites

  • Metrics must be available in the cluster. Niro reads CPU and memory usage from metrics-server. If metrics-server isn’t installed, the rightsizing page will indicate that usage data is unavailable for that cluster.

Reading the recommendations

The rightsizing table shows one row per workload. Each row includes: Niro uses a conservative percentile of observed usage to set the recommended values — the goal is to reduce waste while keeping enough headroom to avoid throttling.

Applying a recommendation via pull request

To update a workload’s resource requests through Git:
1

Select a recommendation

On the Rightsizing page, click a workload to open its recommendation panel.
2

Review the change

Niro shows the current and recommended values side by side. Adjust if needed — the suggested values are a starting point.
3

Open the pull request

Click Apply via PR. Niro opens a pull request in the linked GitHub repo that updates the resources.requests fields in the workload’s manifest.
4

Merge the pull request

Review the changes in GitHub and merge. Niro applies the updated manifest to the cluster automatically (if auto-sync is enabled).
Applying via PR requires the cluster to have a linked GitHub repo and the apply capability enabled. The PR only changes resources.requests — it never reduces below the minimum needed to schedule the pod.

Filtering and sorting

  • Filter by cluster — focus on a specific cluster’s workloads
  • Filter by namespace — narrow to one team’s or service’s workloads
  • Sort by savings — find the highest-impact items first
  • Toggle over/under-requested — see only workloads above the recommendation threshold, or only those below it

Observation window

Recommendations are calculated from recent usage history. A longer window gives more stable recommendations but may not reflect a recent traffic spike. The current window is shown at the top of the rightsizing page.
For workloads with bursty or seasonal traffic, review recommendations during a representative traffic period. Rightsizing during a low-traffic window may produce under-generous limits that don’t hold under peak load.

Cost Monitoring

See how rightsizing changes affect your monthly spend.

Set Up GitOps

Required for applying recommendations via pull request.

Fleet Monitoring

Pod CPU and memory usage at a glance.

Plans

Advisory view is available on all plans. Applying via PR requires Pro.
Last modified on June 19, 2026