OpenShift · Rate Limits
Openshift Rate Limits
OpenShift inherits Kubernetes API Priority and Fairness (APF) flow control on the cluster kube-apiserver. The hosted Red Hat services (Cluster Manager / OCM API) enforce account-scoped throttling but do not publish numeric per-second limits; clients should honor 429 + Retry-After. Concurrent operations on the same resource use optimistic concurrency (resourceVersion); conflict surfaces as HTTP 409.
3 Limits
Throttle: 429
ContainersKubernetesRate Limiting
Limits
kube-apiserver flow control (per cluster) cluster
configured by APF FlowSchemas / PriorityLevelConfigurations on the cluster
Operators can tune APF; defaults reserve capacity for system components and rate-limit other flows.
OpenShift Cluster Manager API (api.openshift.com) account
see Red Hat Cluster Manager docs
Provider-side throttling on the hosted control plane; not published per-tier.
OAuth token endpoint client
see oauth-openshift cluster operator config
Policies
APF fairness
kube-apiserver flow control fairly schedules requests across configured priority levels; excess requests beyond a level's concurrency get queued or rejected with 429.
Backoff
Honor Retry-After on 429 responses; for 409 conflicts, refetch the resourceVersion and retry the update with optimistic concurrency.
Watch and informers
Prefer watch-based informers over polling to avoid API server pressure.
Quota objects
Namespace ResourceQuota and LimitRange objects are admission-time controls, not rate limits — they bound resource consumption, not request frequency.