The Presence Zone Configurator became unusable: "No Room Selected" in the Zone Editor, live tracking stuck on "Waiting for live data", every API request hanging. Reproduced from inside the pod too — even GET / timed out — so it was the app itself, not the Authentik gate.
Root cause
The pod was pegged at 254Mi / 256Mi memory (99%) burning ~0.95 CPU cores — Node/V8 GC-thrash at the cgroup memory limit. The event loop froze so the HTTP server answered nothing, but the process stayed just under the limit → never OOMKilled, never self-recovered (0 restarts, 66d uptime). A rollout restart cleared it (fresh RSS ~115Mi) and the UI — room load, live tracking, zone editing with drag-handles + "Show Zone Slots" — works again.
The heavy device re-discovery triggered by an entity rename (89 entities re-matched + very verbose candidate logging) on top of live tracking pushed a long-lived process over an already-tight 256Mi.
Fix
limits.memory256Mi → 512Mi (headroom below the thrash zone); requests.memory 64Mi → 128Mi (realistic baseline).
Liveness + readinesshttpGet / on the UI port. There was no probe, so the kubelet never restarted the hung server. Now a wedge fails the probe and the pod auto-recycles.
Validation
kubectl kustomize kubernetes/apps/zone-configurator green. Restarted pod verified responsive (inside-pod GET / + /api/rooms OK; gate returns 302; live target tracking confirmed in the browser).
## Symptom
The Presence Zone Configurator became unusable: **"No Room Selected"** in the Zone Editor, live tracking stuck on *"Waiting for live data"*, every API request hanging. Reproduced from **inside the pod** too — even `GET /` timed out — so it was the app itself, not the Authentik gate.
## Root cause
The pod was pegged at **254Mi / 256Mi memory (99%)** burning **~0.95 CPU cores** — Node/V8 **GC-thrash** at the cgroup memory limit. The event loop froze so the HTTP server answered nothing, but the process stayed just under the limit → **never OOMKilled, never self-recovered** (0 restarts, 66d uptime). A rollout restart cleared it (fresh RSS ~115Mi) and the UI — room load, live tracking, zone editing with drag-handles + "Show Zone Slots" — works again.
The heavy device re-discovery triggered by an entity rename (89 entities re-matched + very verbose candidate logging) on top of live tracking pushed a long-lived process over an already-tight 256Mi.
## Fix
- `limits.memory` **256Mi → 512Mi** (headroom below the thrash zone); `requests.memory` 64Mi → 128Mi (realistic baseline).
- **Liveness + readiness** `httpGet /` on the UI port. There was **no probe**, so the kubelet never restarted the hung server. Now a wedge fails the probe and the pod auto-recycles.
## Validation
`kubectl kustomize kubernetes/apps/zone-configurator` green. Restarted pod verified responsive (inside-pod `GET /` + `/api/rooms` OK; gate returns 302; live target tracking confirmed in the browser).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Der Configurator-Pod hing (UI nicht erreichbar, "No Room Selected" beim
Zonen-Editieren, Live-Tracking eingefroren): RSS lag bei 254Mi/256Mi und
~0,95 CPU-Kerne – klassisches Node/V8 GC-Thrashing am cgroup-Memory-Limit.
Der Prozess blieb knapp unter dem Limit, wurde also nie OOMKilled und kam
nie von selbst zurück; ein Neustart hat ihn befreit (frisch ~115Mi).
- limits.memory 256Mi → 512Mi (Headroom gegen GC-Thrash), requests.memory
64Mi → 128Mi (realistischere Baseline).
- Liveness/Readiness httpGet auf / (Port http). Bisher gab es keine Probe,
daher hat kubelet den hängenden Server nie neu gestartet. Jetzt schlägt
die Probe beim Einfrieren fehl und der Pod wird automatisch recycelt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Symptom
The Presence Zone Configurator became unusable: "No Room Selected" in the Zone Editor, live tracking stuck on "Waiting for live data", every API request hanging. Reproduced from inside the pod too — even
GET /timed out — so it was the app itself, not the Authentik gate.Root cause
The pod was pegged at 254Mi / 256Mi memory (99%) burning ~0.95 CPU cores — Node/V8 GC-thrash at the cgroup memory limit. The event loop froze so the HTTP server answered nothing, but the process stayed just under the limit → never OOMKilled, never self-recovered (0 restarts, 66d uptime). A rollout restart cleared it (fresh RSS ~115Mi) and the UI — room load, live tracking, zone editing with drag-handles + "Show Zone Slots" — works again.
The heavy device re-discovery triggered by an entity rename (89 entities re-matched + very verbose candidate logging) on top of live tracking pushed a long-lived process over an already-tight 256Mi.
Fix
limits.memory256Mi → 512Mi (headroom below the thrash zone);requests.memory64Mi → 128Mi (realistic baseline).httpGet /on the UI port. There was no probe, so the kubelet never restarted the hung server. Now a wedge fails the probe and the pod auto-recycles.Validation
kubectl kustomize kubernetes/apps/zone-configuratorgreen. Restarted pod verified responsive (inside-podGET /+/api/roomsOK; gate returns 302; live target tracking confirmed in the browser).🤖 Generated with Claude Code