Troubleshoot Kedify

Start with the symptom. Each runbook separates evidence, a bounded remedy and a recovery check.

Symptom	Runbook
Workload does not scale, or scales slowly	Workload scaling
Recommendations are missing or unexpected	Insights
Cost figures are missing or partial	FinOps data and pricing coverage
Pod resources do not resize	Vertical scaling
Forecasts are missing or inaccurate	Predictive scaling
Remote members or tenant controllers fail	Multi-cluster and tenant controllers
Inference pods are pending or requests are slow	Inference
HTTP requests fail in the proxy path	HTTP logs and error metrics

Collecting Debug Information

Use Collect diagnostics for the plugin command or standalone collection script.

Unknown scaler type kedify-http or kedify-envoy-http

If you deployed a ScaledObject with the trigger kedify-http or kedify-envoy-http and the ScaledObject is not ready, you might encounter one of the following error messages in the KEDA Operator logs:

• no scaler found for type: kedify-http
• no scaler found for type: kedify-envoy-http

This indicates that you are using an unsupported KEDA distribution. These scalers (HTTP and Envoy HTTP) are supported only with the Kedify build of KEDA.

Follow the controlled KEDA migration after inventorying ownership and preserving workload capacity. Do not uninstall an active autoscaler as the first diagnostic step.

Kedify Agent is unable to connect to the Kedify service

The Kedify Agent connects using gRPC over port 443. Check to make sure port 443 is open and you are able to make outbound network connections.

A ScaledObject does not create KPA

KPA requires a compatible Kedify KEDA installation with KPA enabled. Check the ScaledObject annotation and status first:

kubectl get scaledobject <name> -n <namespace> -o yaml
kubectl get kpa,hpa -n <namespace>

autoscaling.kedify.io/class must be kpa, unless the installation default is KPA. KEDA rejects an invalid class, a KPA selection when KPA support is disabled, an explicit class: kpa on an existing ScalingGroup member, or a conflicting autoscaler instead of creating two controllers for the same target. If an explicitly KPA-selected ScaledObject newly matches a ScalingGroup selector, the controller changes the annotation to hpa and emits an AutoscalingClassFallback Warning event before KEDA replaces KPA with HPA. This rewritten HPA choice remains after the object leaves the group; wait for the membership annotation to disappear, then explicitly select kpa again if desired. If KPA came only from the installation default, no class is rewritten: the object uses HPA while it is a group member and follows the installation default again after leaving. Review the ScaledObject events and KEDA operator logs for the exact transition or validation error.

KEDA-generated KPAs support External, Resource, and ContainerResource metrics. The KPA CRD rejects another HPA metric type during API admission. Directly authored KPAs remain unsupported even when their spec passes structural validation.

If KPA exists but cannot fetch an external metric, verify that its paired KEDA operator watches the same namespace and that the KPA-to-KEDA mTLS identity is valid. For CPU or memory, verify that kubectl top pods -n <namespace> works. See Kedify Pod Autoscaler troubleshooting.

Command not found: kubectl

Install kubectl using the Kubernetes instructions for your operating system, then run kubectl version --client. Linux packages require the Kubernetes package repository; an unconfigured apt or yum install is insufficient.

Custom DNS Domain

If your Kubernetes cluster uses a custom DNS domain instead of the standard cluster.local suffix, follow the Custom DNS Domain configuration in the cluster setup guide.

Istio Integration

When setting up Kedify, you might encounter an error like (v1beta1.external.metrics.k8s.io) status FailedDiscoveryCheck if you have Istio installed on the cluster.

To mitigate this problem, follow the Istio Integration in the cluster setup guide.