KEDA · Rate Limits

Keda Rate Limits

KEDA does not operate a hosted API; it is an in-cluster controller plus an external-metrics API server consumed by the Kubernetes HPA. There are no first-party, per-second / per-minute rate limits. Polling cadence and concurrent-event behavior are configured per ScaledObject via pollingInterval, cooldownPeriod, and per-scaler caps.

2 Limits Throttle: 429
AutoscalingCNCFEvent-DrivenGraduatedKubernetesRate Limiting

Limits

ScaledObject pollingInterval scaledobject
poll_seconds
configured per ScaledObject (default 30s)
Effective request rate to the upstream event source is determined by pollingInterval and the number of ScaledObjects targeting it.
External Metrics API (in-cluster) cluster
varies
bounded by Kubernetes apiserver and metrics-server resource limits, not by KEDA

Policies

Polling Cadence
Tune pollingInterval and cooldownPeriod per ScaledObject to balance scaling responsiveness against load on the event source.
Scaler-Side Limits
Each scaler (Kafka, RabbitMQ, SQS, etc.) inherits the rate-limit semantics of the underlying source; KEDA itself does not throttle.
Backoff Strategy
KEDA scalers apply exponential backoff on transient scaler errors before surfacing a ScalerError CloudEvent.

Sources