# GKE Node Pool Auto-Repair Disabled

> Auto-repair replaces GKE nodes that fail health checks; with it off, broken nodes linger in the pool while pods fail to schedule. ZopNight rule RC-1226 evaluates the cluster-level auto_repair flag the discoverer aggregates from every pool's management.autoRepair, firing only on an explicit false: a single opted-out pool trips it.

Source: https://zop.dev/integrations/gcp/recommendations/gke-node-pool-auto-repair-disabled
Updated: 2026-08-19

---

## Why this finding lands on the cluster, not the pool

An implementation detail worth understanding before you go looking for the culprit: the GCP discoverer aggregates every node pool's `management.autoRepair` into one cluster-level `auto_repair` flag: false if any pool has repair off, true only when all do, omitted when there are no pools to inspect. Rule RC-1226 reads that aggregate (metadata first, tags mirror as fallback) and fires only on the explicit `false`; the omitted case abstains, fail-closed. The per-pool enrichment never carries the flag at all, which is why the finding names the cluster and leaves identifying the offending pool to you:

```bash
gcloud container node-pools list --cluster my-cluster --location us-central1 \
  --format='table(name,management.autoRepair)'
```

## The slow rot of a pool without repair

Auto-repair is GKE's janitor: when a node fails consecutive health checks (NotReady beyond the tolerance window, disk pressure, a wedged kubelet), GKE drains and recreates it. With repair disabled, that node simply stays. Kubernetes reschedules what it can onto the healthy remainder, shrinking real capacity while the pool's node count still looks right; autoscaling reasons over nodes that exist but do not work. The degradation is invisible until enough nodes have rotted that pods go Pending, at which point the on-call inherits a fleet-health backlog that a janitor process would have handled one node at a time. Broken-but-present nodes also keep billing. An unhealthy node is pure waste until someone notices.

## The one honest reason it gets disabled

Pools running stateful daemons or licensed software sometimes turn repair off because an automatic node replacement is genuinely disruptive to them. If that trade-off is deliberate, document it against the pool and accept the standing finding. The rule cannot read intent. What it flags is the far more common case: repair switched off during an old incident and never restored.

## Restore the default

```bash
gcloud container node-pools update my-pool --cluster my-cluster \
  --location us-central1 --enable-autorepair
```

Confirm capacity headroom first: a pool at the edge of its resources needs room to host a node's pods during each repair cycle. Pair it with auto-upgrade, which the sibling RC-120 rule checks; the two management flags cover failure and staleness respectively, and pools healthy on both dimensions need neither finding again.