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

# Resource Overrides

> Set per-workload floors and ceilings to constrain what Autopilot recommends — the operator guardrails that always win over the algorithm.

Autopilot's recommendations are usually right, but sometimes you know something the metrics
don't — a workload needs a minimum reservation for a cold cache, or must never exceed a hard
budget. **Resource Overrides** are per-workload annotations that constrain what Autopilot may
recommend. They're the operator's guardrails, and they **always win over the algorithm**.

## Floors and ceilings

Set annotations on a Deployment or StatefulSet. A **floor** clamps the recommendation upward
(never go below); a **ceiling** clamps it downward (never go above).

| Annotation                   | Example        | Effect                                      |
| ---------------------------- | -------------- | ------------------------------------------- |
| `ops-ai.io/min-cpu`          | `1000m`, `2`   | CPU request never recommended below this    |
| `ops-ai.io/min-memory`       | `2Gi`, `512Mi` | Memory request never recommended below this |
| `ops-ai.io/max-cpu`          | `2000m`        | CPU request never recommended above this    |
| `ops-ai.io/max-memory`       | `4Gi`          | Memory request never recommended above this |
| `ops-ai.io/max-cpu-limit`    | `4000m`        | CPU limit never recommended above this      |
| `ops-ai.io/max-memory-limit` | `8Gi`          | Memory limit never recommended above this   |

Behavior: floor clamps up, ceiling clamps down, and ceiling is applied after floor. A ceiling
also overrides the CPU downscale-delay hold — an operator ceiling is an explicit directive. The
API validates that floor ≤ ceiling for each resource pair.

## Setting them

Three ways, all equivalent:

* **Workload detail** — the edit form has Min/Max fields per resource row, with a "set to recommended" helper and an over-recommendation warning.
* **Resource Overrides page** — a namespace-grouped find-and-clean tool: groups sorted by locked vCPU, multi-select with a bulk-remove bar, and "wants Xm" stale-floor badges when a floor now sits above what the algorithm wants.
* **API / bulk** — `PATCH /api/v1/overrides/{ns}/{name}/floor` for one workload, or `POST /api/v1/overrides/bulk` to apply set/remove across up to 500 workloads at once.

<Note>
  A **system-managed** eviction memory floor is separate from these operator floors: when a
  workload is evicted under node memory pressure, Autopilot ratchets a memory floor from the
  observed usage (decaying after 7 days) so it isn't repeatedly evicted. It's shown as an amber
  "eviction floor" badge and can't be lowered below by a recommendation.
</Note>

## Alert suppression

Related per-workload annotations let you silence a noisy health alert on a specific workload —
useful when a tenant won't fix a known issue and you don't want it dragging cluster health:

| Annotation                        | Example                 | Effect                                   |
| --------------------------------- | ----------------------- | ---------------------------------------- |
| `ops-ai.io/suppress-alert`        | `oom-death-spiral`      | Comma-separated alert types to suppress  |
| `ops-ai.io/suppress-alert-reason` | `tenant refuses to fix` | Why it's suppressed                      |
| `ops-ai.io/suppress-alert-review` | `2026-05-15`            | Optional review date; overdue is flagged |

A suppressed alert stays visible in the health detail panel (and on the Resource Overrides
page's suppressions list) but no longer affects the cluster's overall health status. Set and
remove them from the health panel's per-workload "Suppress" button.