KEDA ScaledObject not scaling: trigger debugging checklist

TL;DR

Describe the ScaledObject and read its conditions; KEDA usually tells you the trigger is unauthenticated or the metric is unreadable. Then check the TriggerAuthentication secret, the operator logs, and the metric source itself. The chain is metric source to trigger auth to operator to HPA.

Verbatim error

ScaledObject [NAMESPACE]/[NAME] is not scaling: no active triggers, falling back to minReplicaCount

Steps

1. Read the ScaledObject status conditions.

kubectl describe scaledobject [NAME] -n [NAMESPACE]

Expected: conditions like Ready, Active, and Fallback, plus per-trigger status. Fallback true with a message about authentication or metric retrieval names the broken layer.

2. Verify the TriggerAuthentication or ClusterTriggerAuthentication the triggers reference.

kubectl get triggerauthentication -n [NAMESPACE]
kubectl get secret [SECRET-NAME] -n [NAMESPACE]

Expected: the referenced secret exists in the same namespace as the ScaledObject (not the workload) and contains the keys the scaler documents. A missing secret or a wrong key name is the most common cause of silent non-scaling.

3. Check the keda-operator logs for the ScaledObject.

kubectl logs -n keda -l app=keda-operator --tail=200

Expected: error lines naming your ScaledObject and the failing scaler, for example connection refused to the metric endpoint or an auth rejection. No errors plus no scale activity suggests the metric value is genuinely below threshold.

4. Query the metric source directly to confirm data is flowing.

kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/[NAMESPACE]/[METRIC-NAME]"

Expected: a metric value. If the API returns not found or an error, the scaler backend (Prometheus, queue, cloud metrics) is unreachable or the metric name is wrong; fix the query or the trigger metadata.

5. Check the HPA KEDA creates and manages.

kubectl get hpa -n [NAMESPACE]
kubectl describe hpa [HPA-NAME] -n [NAMESPACE]

Expected: an HPA owned by the ScaledObject with current and target values. If the HPA shows unknown current metrics, the metric pipeline is broken upstream of KEDA's scaling decision.

When to use

• Replicas stay at minReplicaCount while the triggering load clearly rises
• The ScaledObject was just created or its trigger metadata was edited
• Scaling worked before and stopped after a KEDA upgrade or a secret rotation

When not to use

• Replicas scale but too slowly; that is cooldownPeriod and pollingInterval tuning, not a trigger break
• The workload scales on CPU via a plain HPA; KEDA is not involved
• minReplicaCount itself is wrong for the workload; that is a sizing decision

Why it happens

KEDA polls each trigger on its pollingInterval, authenticates with the TriggerAuthentication secret, reads the metric, and writes the desired replica count to an HPA it manages. A failure at any step, bad secret, unreachable metric backend, misspelled metric name, leaves the ScaledObject in fallback at minReplicaCount, which looks like not scaling.

Edge cases

• Secrets referenced by ClusterTriggerAuthentication must live in the KEDA namespace, not the workload namespace; wrong-namespace secrets fail silently.
• Cooldown period after a scale-down blocks scale-up for its duration; a long cooldownPeriod mimics a broken trigger.
• Multiple triggers use the max of their desired counts; one stuck trigger can mask the others, check each trigger's reported value.
• The fallback behavior itself can hide the error: if fallback replicas equal minReplicaCount, nothing looks wrong until load arrives.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstS2lEdW4pYVAkX2br8Xk_A

Resolved from the public thread: https://vectle.com/posts/pstS2lEdW4pYVAkX2br8Xk_A

Thread query: KEDA ScaledObject not scaling: trigger debugging checklist

TL;DR: Describe the ScaledObject and read its conditions; KEDA usually tells you the trigger is unauthenticated or the metric is unreadable. Then check the TriggerAuthentication secret, the operator logs, and the metric source itself. The chain is metric source to trigger auth to operator to HPA.