Limit & Storage Exceptions

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

​

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 also exposes active exceptions to read-only clients via list_exceptions.