unscaled
Your HPA is configured, healthy, and has never added a pod.
---
The problem
# deployment.yaml — resources set, but only limits
resources:
limits:
cpu: "1"
---
# hpa.yaml
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
**`Utilization` is a percentage of the pod's CPU *request*.** There is no request here, so there is nothing to divide by. The metrics pipeline returns nothing usable, and the HPA holds at `minReplicas` through any amount of load.
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS api Deployment/api <unknown/70% 2 20 2
That `<unknown>` is the only place it is ever said.
The manifest applied cleanly. `kubectl apply` was happy, `kubeconform` validated it, the HPA reconciles, it reports `Ready`, and every inventory of your autoscalers counts it. It has been inert since the day it was created, and it will still be inert during the incident — where the symptom is a service that does not scale, which looks exactly like a service that did not need to.
The same silence covers a `scaleTargetRef` pointing at a Deployment that was renamed, a KEDA trigger whose `TriggerAuthentication` is not deployed, and a `replicas:` field that an Argo sync resets every few minutes while the autoscaler moves it back.
$ npx unscaled .
3 autoscalers · 1 can scale · 2 would never add a pod ██████████ 33% would respond to load
3 manifests · 3 workloads
error utilization-target-without-request api.yaml:26 HorizontalPodAutoscaler/api scales on cpu utilisation, and its only container in Deployment/api requests no cpu fix: Set resources.requests.cpu on every container in Deployment/api. Alternatively target AverageValue instead of Utilization, which is an absolute figure and needs no request. api.yaml:3 — container api has no cpu request
error trigger-authentication-missing worker.yaml:22 1 KEDA trigger references a TriggerAuthentication that is not here worker.yaml:22 — order-worker references rabbitmq-auth
warning replicas-pinned-under-autoscaler api.yaml:3 1 workload sets replicas while an autoscaler also manages the count
## Why existing tools miss it
| Tool | Why this is invisible to it |
|---|---|
| `kubectl apply`, `kubeconform`, `kubeval` | The manifests are valid. Every field is the right type. Nothing here is a schema error. |
| `kube-linter` | Has `dangling-hpa` for a missing target — genuinely useful, and the overlap is acknowledged. It does not relate the HPA's *metric* to the target's *requests*, which is the failure that produces `<unknown>`. |
| `kube-score`, `polaris` | Check that requests exist as a general best practice. They do not know an HPA depends on this specific one, so the finding is advice among a hundred others rather than "this autoscaler cannot work". |
| Your monitoring | There is no error to alert on. The HPA is `Ready`, the pods are healthy, the deployment is available. |
unscaled asks one question instead: **given these manifests, would this autoscaler ever add a pod?**
npx unscaled . # no install
npm install --save-dev unscaledNode 20.10 or newer. Zero runtime dependencies. No cluster, no kubeconfig, no network.