Workload does not scale, or scales too slowly

Start with the first layer whose evidence differs from the expected result. A desired replica count is not proof that pods are ready or that requests succeed.

Collect a bounded snapshot

Choose the affected namespace and ScaledObject. Commands below inspect state; they do not change capacity.

kubectl get scaledobject -n <namespace> <name> -o yaml
kubectl get hpa -n <namespace>
kubectl get pods -n <namespace> -o wide
kubectl get events -n <namespace> --sort-by=.lastTimestamp

If KPA is installed, also inspect kubectl get kpa -n <namespace>. Record timestamps, demand and the configured min/max replicas, cooldown and scaling behavior.

Workload does not scale out

Evidence	Investigate	Bounded action and recheck
ScaledObject is not Ready	Trigger type, authentication, endpoint, target identity, admission/controller errors	Correct the reported field or access through its owner; recheck Ready and fresh source metrics.
Source metric is absent or stale	Upstream source/collector, labels, query and network path	Query the source first. Restore ingestion or fix selection; verify timestamps before changing targets.
Source has demand but workload stays at zero	Activation threshold, scale-to-zero signal availability, paused state	Verify the selected scaler can observe demand while pods are stopped; inspect KEDA events. CPU from stopped pods cannot supply that evidence.
Desired count reaches maximum	Configured cap or ScalingGroup capacity	Check the capacity owner’s limits and downstream constraints before increasing the cap.
Desired count rises but pods remain Pending	Node resources, quota, affinity, volumes or GPU/device availability	Read scheduler events; restore feasible capacity. Changing the trigger cannot resolve unschedulable pods.
Pods start but are not Ready	Image pulls, startup/readiness probes, model initialization or dependency failure	Fix the startup failure and measure time to ready; review workload readiness.

Workload does not scale in

Check for an active signal, nonzero minimum replicas, cooldown and stabilization windows, paused annotations and multiple triggers. KEDA/HPA selection rules may retain capacity when one trigger remains high. Check in-flight requests or unacknowledged queue work before reducing capacity. Use horizontal tuning and maintenance annotations to interpret the configured behavior.

Wrong controller or competing writers

Check owner references and target names. Do not manually edit generated HPA/KPA resources while the ScaledObject owner recreates them. A resource-changing controller and GitOps can also disagree about pod requests. Use controller combination rules and tenant ownership diagnostics.

Follow the responsible subsystem

• Requests fail or wait: HTTP logs and error metrics.
• Recommendations are missing: Insights diagnostics.
• Resources do not resize: vertical scaling diagnostics.
• Forecast is absent or wrong: predictive diagnostics.
• Remote members or tenant controllers fail: platform diagnostics.
• Inference is slow or GPU pods are pending: inference diagnostics.

After a remedy, repeat the same demand and compare source signal, activation, desired count, ready count and application outcome. If unresolved, collect diagnostics with the affected object, timestamps and the first failing layer.

Check metrics and telemetry

When dashboard or monitoring data is missing, compare the component’s own metric with the same series in your backend. Check namespace labels and timestamps, then inspect scrape/export errors if the source is fresh but the backend is stale. Metrics reference identifies the emitters and units.

Run Autoscaling Checks to exercise a canary scaling path independently of the affected application. For HTTP failures, inspect proxy logs and error metrics or trace the proxy/interceptor path.