> ## Documentation Index
> Fetch the complete documentation index at: https://docs.niro.cx/llms.txt
> Use this file to discover all available pages before exploring further.

# Rightsizing

> Find workloads that are over- or under-requested compared to actual usage, and resize CPU and memory via pull request.

## 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 <Badge>Pro</Badge>.

## Prerequisites

* Metrics must be available in the cluster. Niro reads CPU and memory usage from [metrics-server](https://github.com/kubernetes-sigs/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:

| Column                     | Description                                                                                         |
| -------------------------- | --------------------------------------------------------------------------------------------------- |
| **Workload**               | Name, namespace, and cluster                                                                        |
| **Current CPU request**    | CPU currently reserved per pod                                                                      |
| **Recommended CPU**        | Suggested request based on observed peak usage                                                      |
| **Current memory request** | Memory currently reserved per pod                                                                   |
| **Recommended memory**     | Suggested request based on observed peak usage                                                      |
| **Savings estimate**       | Monthly cost delta if the recommendation is applied (requires [cost configuration](/features/cost)) |

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:

<Steps>
  <Step title="Select a recommendation">
    On the Rightsizing page, click a workload to open its recommendation panel.
  </Step>

  <Step title="Review the change">
    Niro shows the current and recommended values side by side. Adjust if needed — the suggested values are a starting point.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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).
  </Step>
</Steps>

<Note>
  Applying via PR requires the cluster to have a [linked GitHub repo](/guides/gitops) and the apply capability enabled. The PR only changes `resources.requests` — it never reduces below the minimum needed to schedule the pod.
</Note>

## 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.

<Tip>
  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.
</Tip>

## Related

<CardGroup cols={2}>
  <Card title="Cost Monitoring" icon="coin" href="/features/cost">
    See how rightsizing changes affect your monthly spend.
  </Card>

  <Card title="Set Up GitOps" icon="code-branch" href="/guides/gitops">
    Required for applying recommendations via pull request.
  </Card>

  <Card title="Fleet Monitoring" icon="gauge" href="/guides/fleet-monitoring">
    Pod CPU and memory usage at a glance.
  </Card>

  <Card title="Plans" icon="credit-card" href="/reference/plans">
    Advisory view is available on all plans. Applying via PR requires Pro.
  </Card>
</CardGroup>