dae4e8a135
schemas / vulnerabilities (pull_request) Successful in 2m7s
schemas / check (pull_request) Successful in 2m52s
schemas / check-release (pull_request) Successful in 5m32s
pre-commit / pre-commit (pull_request) Successful in 7m2s
schemas / build (pull_request) Successful in 6m24s
schemas / deploy-prod (pull_request) Has been skipped
HPA was pinning the deployment at maxReplicas (4) even though aggregate CPU usage was low. The service is event-driven: pods sit at ~0-1m idle but spike to 100-300m per supergraph query. With requests.cpu=20m those bursts read as 500-1500% utilization, so the HPA's 60% target was constantly exceeded on whichever pod handled the request. Raise the request to 100m so bursts read as 100-300% instead. Combined with the HPA's downscale stabilization window this lets replicas settle back to minReplicas (2) between bursts.