fix: surface HPA errors on ScaledObject

[wozniakjan]

KEDA's ScaledObject currently reports Ready=True even when its managed HPA cannot fetch metrics (HPA shows <unknown> targets with ScalingActive=False). Users see a healthy-looking ScaledObject while scaling is silently broken, the only way to discover the problem is to manually inspect the HPA. Examples of this might be broken metrics adapter, broken APIService.apiregistration, or invalid certs for the gRPC connection between operator and metrics adapter.

HPA broken with adapter not running

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: keda-hpa-nginx
  namespace: keda
spec:
  maxReplicas: 10
  metrics:
  - external:
      metric:
        name: s0-configmap-mock-metric-metric-value
        selector:
          matchLabels:
            scaledobject.keda.sh/name: nginx
      target:
        averageValue: "5"
        type: AverageValue
    type: External
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
status:
  conditions:
  - lastTransitionTime: "2026-04-20T08:49:50Z"
    message: the HPA controller was able to get the target's current scale
    reason: SucceededGetScale
    status: "True"
    type: AbleToScale
  - lastTransitionTime: "2026-04-20T10:26:40Z"
    message: 'the HPA was unable to compute the replica count: unable to get external
      metric keda/s0-configmap-mock-metric-metric-value/&LabelSelector{MatchLabels:map[string]string{scaledobject.keda.sh/name:
      nginx,},MatchExpressions:[]LabelSelectorRequirement{},}: unable to fetch metrics
      from external metrics API: the server is currently unable to handle the request
      (get s0-configmap-mock-metric-metric-value.external.metrics.k8s.io)'
    reason: FailedGetExternalMetric
    status: "False"
    type: ScalingActive
  - lastTransitionTime: "2026-04-20T08:49:50Z"
    message: the desired count is within the acceptable range
    reason: DesiredWithinRange
    status: "False"
    type: ScalingLimited
  currentMetrics:
  - type: ""
  currentReplicas: 4
  desiredReplicas: 4
  lastScaleTime: "2026-04-20T08:49:50Z"

Former SO status reporting when HPA is broken

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: nginx
  namespace: keda
spec:
  maxReplicaCount: 10
  minReplicaCount: 1
  scaleTargetRef:
    kind: Deployment
    name: nginx
  triggers:
  - metadata:
      key: metric-value
      resourceKind: ConfigMap
      resourceName: mock-metric
      targetValue: "5"
    type: kubernetes-resource
status:
  authenticationsTypes: ""
  conditions:
  - message: ScaledObject is defined correctly and is ready for scaling
    reason: ScaledObjectReady                                       # <-- imho this is incorrect
    status: "True"
    type: Ready
  - message: Scaling is performed because triggers are active
    reason: ScalerActive                                            # <- debatable whether active should be true?
    status: "True"
    type: Active
  - message: No fallbacks are active on this scaled object
    reason: NoFallbackFound
    status: "False"
    type: Fallback
  - status: "False"
    type: Paused
  externalMetricNames:
  - s0-configmap-mock-metric-metric-value
  hpaName: keda-hpa-nginx
  lastActiveTime: "2026-04-20T10:25:31Z"
  originalReplicaCount: 1
  scaleTargetGVKR:
    group: apps
    kind: Deployment
    resource: deployments
    version: v1
  scaleTargetKind: apps/v1.Deployment
  triggersActivity:
    s0-configmap-mock-metric-metric-value:
      isActive: true
  triggersTypes: kubernetes-resource

Proposed SO status reporting when HPA is broken

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: nginx
  namespace: keda
spec:
  maxReplicaCount: 10
  minReplicaCount: 1
  scaleTargetRef:
    kind: Deployment
    name: nginx
  triggers:
  - metadata:
      key: metric-value
      resourceKind: ConfigMap
      resourceName: mock-metric
      targetValue: "5"
    type: kubernetes-resource
status:
  authenticationsTypes: ""
  conditions:
  - message: 'ScaledObject is configured correctly but HPA is not healthy: FailedGetExternalMetric'
    reason: HPAMetricsUnavailable                                    # <- no longer reported as ready
    status: "False"
    type: Ready
  - message: Scaling is performed because triggers are active
    reason: ScalerActive                                             # <- still reports as active
    status: "True"
    type: Active
  - message: No fallbacks are active on this scaled object
    reason: NoFallbackFound
    status: "False"
    type: Fallback
  - status: "False"
    type: Paused
  externalMetricNames:
  - s0-configmap-mock-metric-metric-value
  hpaName: keda-hpa-nginx
  lastActiveTime: "2026-04-20T10:27:01Z"
  originalReplicaCount: 1
  scaleTargetGVKR:
    group: apps
    kind: Deployment
    resource: deployments
    version: v1
  scaleTargetKind: apps/v1.Deployment
  triggersActivity:
    s0-configmap-mock-metric-metric-value:
      isActive: true
  triggersTypes: kubernetes-resource

Checklist

• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added (if applicable)
• Ensure make generate-scalers-schema has been run to update any outdated generated files
• Changelog has been updated and is aligned with our changelog requirements, only when the change impacts end users
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #7649

[github-actions]

Thank you for your contribution! 🙏

Please understand that we will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Once the initial tests are successful, a KEDA member will ensure that the e2e tests are run. Once the e2e tests have been successfully completed, the PR may be merged at a later date. Please be patient.

Learn more about our contribution guide.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[Copilot]

Pull request overview

Surfaces managed HPA health problems on the ScaledObject by adjusting the Ready condition when the HPA cannot compute metrics (e.g., ScalingActive=False).

Changes:

• Add HPA health evaluation during RequestScale and aggregate it into the ScaledObject Ready condition.
• Introduce new Ready condition reasons: HPAMetricsUnavailable and ScalingDegraded.
• Add unit tests for HPA health evaluation and update CHANGELOG.md.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
pkg/scaling/executor/scale_scaledobjects.go	Adds HPA health reading (via autoscaling/v2 HPA status) and Ready-condition aggregation in RequestScale.
pkg/scaling/executor/scale_scaledobjects_test.go	Adds tests for HPA health logic and Ready-condition aggregation behavior.
apis/keda/v1alpha1/condition_types.go	Adds new ScaledObject Ready condition reason constants used by the executor.
CHANGELOG.md	Documents the user-facing behavior change for ScaledObject Ready condition vs HPA health.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wozniakjan]

/run-e2e
Update: You can check the progress here

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wozniakjan]

/run-e2e
Update: You can check the progress here

[wozniakjan]

/run-e2e
Update: You can check the progress here

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wozniakjan]

/run-e2e
Update: You can check the progress here

[JorTurFer]

I like this idea, but I'm not sure if checking this makes sense here. I mean this will check the HPA on each controller loop, which means an extra request to the API (I know that it's cached).

The HPA is alreade added to ScaledObjectController's reconcilliation loop

keda/controllers/keda/scaledobject_controller.go

Lines 145 to 150 in 1b105b3

	Owns(&autoscalingv2.HorizontalPodAutoscaler{}, builder.WithPredicates(
	predicate.Or(
	predicate.LabelChangedPredicate{},
	predicate.AnnotationChangedPredicate{},
	kedacontrollerutil.HPASpecChangedPredicate{},
	))).

Does it make sense to include the change of these fields in predicates and manage changes via watch instead of regular checks?

[wozniakjan]

Does it make sense to include the change of these fields in predicates and manage changes via watch instead of regular checks?

I did a little bit of digging into the history (more on the issue #7649), apparently that was how KEDA had it before and it was causing too frequent reconciliations and unnecessary condition flapping. Per my testing, HPA really can throw a good number of events leading to extremely frequent reconciles. It was enough to have 200 SOs in cluster with trigger-happy HPAs to take KEDA effectively down.

which means an extra request to the API (I know that it's cached)

exactly, because this uses cached client, it's read from memory => 0 extra API calls.

[wozniakjan]

/run-e2e
Update: You can check the progress here

[wozniakjan]

/run-e2e
Update: You can check the progress here

thanks! fixed, ptal

[rickbrouwer]

/run-e2e
Update: You can check the progress here

[wozniakjan]

/run-e2e
Update: You can check the progress here

[semgrep-code-kedacore]

Semgrep found 12 context-todo findings:

• pkg/scaling/executor/scale_scaledobjects_test.go
  • L765 - Triage
  • L784 - Triage
  • L808 - Triage
  • L832 - Triage
  • L858 - Triage
  • L883 - Triage
  • L962 - Triage
  • L983 - Triage
  • L1004 - Triage
  • L1024 - Triage
  • 2 more - Triage

Consider to use well-defined context

[wozniakjan]

/run-e2e ^tests/(internals|secret-providers|scalers/(datadog|[^d][^/]))/._test.go$

skip dynatrace - its CI secret DYNATRACE_HOST returns 404, unrelated to this PR

Update: You can check the progress here

[wozniakjan]

/run-e2e internal
Update: You can check the progress here

the only thing that failed in #7669 (comment) were dynatrace tests (they have unrelated issue, 404 to putting metrics to the project). With #7669 (comment) I probably abused regex too much, tests weren't even triggered, so just a last sanity check before merging running for internal e2es