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.

Keda Rate Limits is the machine-readable rate-limit profile for KEDA on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 2 rate-limit definitions, measuring poll_seconds and varies.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled and serviceUnavailable.

Tagged areas include Autoscaling, CNCF, Event-Driven, Graduated, and Kubernetes.

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