Learn KEDA - Fallback & Advanced Config
Securing autoscaling with fallback when a scaler fails, then setting pollingInterval, cooldownPeriod, restoreToOriginalReplicaCount, HPA behavior, and scalingStrategy for precise scaling behavior.
#Introduction
In episode 10 you learned how to build any scaler — including a custom gRPC one. But one important question remains unanswered: what happens when that scaler fails? A broker dies, a query errors, credentials expire. In this episode we cover fallback to keep minimum availability, then set up advanced config: pollingInterval, cooldownPeriod, restoreToOriginalReplicaCount, HPA behavior, and scalingStrategy. These are the knobs that separate flapping autoscaling from stable autoscaling in production.
#Fallback: Keeping Minimum Availability
When a scaler fails to read metrics, KEDA must not let the workload shrink to zero — that's exactly the moment you need consumers to drain the remaining work. That's the job of the fallback block.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: order-worker-scaler
spec:
scaleTargetRef:
name: order-worker
minReplicaCount: 0
maxReplicaCount: 30
fallback:
failureThreshold: 3
replicas: 2
pollingInterval: 30
triggers:
- type: aws-sqs-queue
metadata:
awsRegion: ap-southeast-3
queueURL: https://sqs.ap-southeast-3.amazonaws.com/123456789012/orders
queueLength: "10"failureThreshold: 3 means that after 3 consecutive failed polls, KEDA forces the replicas to replicas: 2. Once the scaler recovers, KEDA returns to normal scaling logic.
Warning
Fallback isn't an absolute minimum — it only activates when the scaler actually fails, not when metrics are low. Don't use it as a substitute for minReplicaCount. Verify its status via the Fallback condition in kubectl describe scaledobject order-worker-scaler -n production.
| Command | Function |
|---|---|
kubectl get scaledobject | grep keda | List KEDA's ScaledObjects |
kubectl describe scaledobject <name> -n <ns> | Condition details including Fallback |
kubectl get hpa -n <ns> | View the HPA created by KEDA |
#pollingInterval vs cooldownPeriod
These two parameters are often confused. pollingInterval is how often KEDA checks metrics from the scaler (default 30 seconds). cooldownPeriod is how long KEDA waits before allowing HPA to scale down after metrics drop (default 300 seconds).
| Parameter | Default | Function |
|---|---|---|
pollingInterval | 30 seconds | How often metrics are fetched from the scaler |
cooldownPeriod | 300 seconds | Delay before scale-down begins |
activationThreshold | 0 | Threshold before pods are activated from zero |
Tip
Lower pollingInterval for faster responses to spikes, but be aware that every poll triggers a request to the external system — too aggressive and you can hit provider rate limits. Raise cooldownPeriod for workloads with expensive cold starts so replicas aren't scaled up and down needlessly.
#restoreToOriginalReplicaCount
When a ScaledObject is deleted, KEDA by default scales the Deployment according to minReplicaCount — which could be zero. With restoreToOriginalReplicaCount: true, KEDA restores the Deployment to the replica count it had before the ScaledObject was created.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: order-worker-scaler
spec:
scaleTargetRef:
name: order-worker
restoreToOriginalReplicaCount: true
minReplicaCount: 0
maxReplicaCount: 30
triggers:
- type: aws-sqs-queue
metadata:
awsRegion: ap-southeast-3
queueURL: https://sqs.ap-southeast-3.amazonaws.com/123456789012/orders
queueLength: "10"Note
This feature only applies when the ScaledObject is deleted, not during normal scaling. If the Deployment already had 0 replicas before the ScaledObject was created, it will go back to 0 as well.
#HPA Behavior: scaleUp and scaleDown
KEDA forwards behavior directly to the HPA it creates. This is where you control how fast replicas are increased and decreased.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: web-scaler
spec:
scaleTargetRef:
name: web
minReplicaCount: 0
maxReplicaCount: 20
advanced:
horizontalPodAutoscalerConfig:
behavior:
scaleUp:
stabilizationWindowSeconds: 0
policies:
- type: Percent
value: 100
periodSeconds: 15
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 25
periodSeconds: 60
triggers:
- type: cpu
metricType: Utilization
metadata:
type: Utilization
value: "60"scaleUp with stabilizationWindowSeconds: 0 makes scaling up as fast as possible — up to 100 percent additional replicas every 15 seconds. scaleDown is kept slow with a 300-second window to avoid flapping amid fluctuating load.
#scalingStrategy
scalingStrategy.strategy controls how KEDA calculates the metric value reported to HPA when there are many triggers.
| Strategy | Behavior |
|---|---|
default | Sums the values of all triggers |
custom | Custom formula with customScalingQueueLengthDeduction to reduce over-provisioning |
accurate | Available for ScaledJob; calculates the queue that's really available |
efficient | Available for ScaledJob; subtracts replicas that are still busy |
For ScaledObject, the available options are default and custom. The accurate and efficient strategies are used on ScaledJob.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: worker-scaler
spec:
scaleTargetRef:
name: worker
minReplicaCount: 0
maxReplicaCount: 20
advanced:
scalingStrategy:
strategy: "custom"
customScalingQueueLengthDeduction: 2
triggers:
- type: rabbitmq
metadata:
queueName: jobs
queueLength: "5"Here every replica count is reduced by 2 — useful when each replica processes several messages at once and you want to avoid over-provisioning.
Tip
Combine all three knobs: scalingStrategy to reduce over-provisioning, fast scaleUp to respond to spikes, and slow scaleDown for stability. That's the recipe for autoscaling that doesn't flap.
#Conclusion
- Fallback:
failureThreshold+replicaskeeps minimum availability when a scaler fails. - pollingInterval controls check frequency; cooldownPeriod controls the delay before scale-down.
restoreToOriginalReplicaCountrestores the original replicas when a ScaledObject is deleted.- HPA behavior: fast scaleUp, slow scaleDown for stability.
- scalingStrategy default sums triggers; custom reduces over-provisioning.
All of this config works behind HPA and ScaledObject. In episode 12 we dive fully into the most anticipated add-on: KEDA HTTP Add-on — the interceptor and operator architecture, HTTPScaledObject, hosts, timeout, handling requests during scale-to-zero, and its limitations on Kubernetes 1.30. See you there!