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

# Limit & Storage Exceptions

> When a workload OOMs at its limit or a PVC fills up, Autopilot files a tracked exception with a clear approve/expand/acknowledge workflow — instead of silently fighting the symptom.

Some events need a decision, not an automatic reaction — a container that OOMs at its memory
**limit**, or a **PVC** that's filling toward full. Autopilot detects these, files a tracked
**exception** CRD, and gives operators a clear workflow to resolve it. Nothing is silently
raised or expanded behind your back.

## Limit Exceptions

When `limitOverage.enabled` is set, a container that gets **OOM-killed at its limit** (not
just its request) triggers a `LimitException` — because raising the request won't help; the
ceiling itself is too low.

* **Standard workloads** get an automatic **limit raise**, recorded as an exception you can approve as the new normal or reject to revert.
* **HPA-managed workloads** get a **`minReplicas` bump** instead — but only when running *at* `minReplicas` (if the HPA has already scaled up, more replicas won't fix the OOM, so it falls back to raising the memory limit).
* A **terminated-pod scan** catches OOM signals on `Failed` pods whose Deployment created a fresh replacement (the running replica has no OOM history), so an OOM-at-limit is never missed.

Each exception has a lifecycle you drive from the dashboard: **approve** (make the raise
permanent) or **reject** (revert). A bulk review page and a per-namespace tab surface them.

## Storage Exceptions

A scanner watches PVC usage (via Prometheus `kubelet_volume_stats_*`) and files a
`StorageException` when a volume crosses its threshold (default 90%). From the dashboard you
can:

| Action          | Effect                                                                        |
| --------------- | ----------------------------------------------------------------------------- |
| **Expand**      | Grow the PVC (irreversible; re-checks that the StorageClass allows expansion) |
| **Acknowledge** | Mark it handled without expanding                                             |
| **Snooze**      | Silence it for a duration; it auto-reopens on expiry                          |
| **Reopen**      | Bring back an acknowledged or snoozed exception                               |

States flow `Detected → Snoozed / Expanded / Acknowledged / CapacityExhausted`. An **auto-expand**
option (with a ceiling) can grow a volume automatically as it fills, and every expansion is
audited with an operator note. Snoozed exceptions show a live countdown.

<Note>
  Direct PVC management (expand any healthy PVC without waiting for an exception, set per-PVC
  ceilings/thresholds/auto-expand) lives on the **Storage** page — see [Storage](/platform/storage).
  The exception workflow here is for volumes that have already crossed a threshold.
</Note>

## Where to find them

Both have dedicated dashboard pages (**Limit Exceptions**, **Storage Exceptions**) and a tab on
each namespace's detail page. The [MCP server](/reference/mcp-server) also exposes active
exceptions to read-only clients via `list_exceptions`.