Linkerd · Rate Limits

Linkerd Rate Limits

Linkerd does not run as a SaaS — APIs are exposed on cluster (proxy admin on port 4191 per pod, control-plane gRPC services). There is no provider-side rate limit on Linkerd's APIs themselves; throughput is bounded by your Kubernetes cluster's CPU / memory / network. Linkerd does enforce circuit-breaking and retry budgets on the data plane; those are the rate-limit-like primitives users typically configure.

4 Limits
Rate LimitingService MeshKubernetesObservability

Limits

Proxy admin API (per pod) pod
requests_per_second
bounded by pod resource budget
Admin server on port 4191 per meshed pod. No documented hard rate cap; bound by CPU / memory allocated to the proxy container.
Control-plane gRPC APIs (Destination / Identity / Policy) cluster
requests_per_second
bounded by control-plane replica count and resource budget
Scale by adding control-plane replicas; not throttled by Linkerd itself.
Data-plane retry budget service
retry_ratio
0.2
Default retry budget is 20% of original request rate. Configurable via ServiceProfile / HTTPRoute retryBudget.
Circuit breaker (failure_accrual) endpoint
consecutive_failures
7
Default failure_accrual breaks an endpoint after a rolling window of consecutive 5xx responses; tunable per ServiceProfile.

Policies

Self-hosted, no provider quota
Linkerd runs in your cluster; there is no Buoyant- or Linkerd-side per-call quota. Cluster capacity is the limit.
Retry budget over fixed retries
Linkerd uses retry budgets (ratio of retries to original requests) rather than per-request max-retry counts to prevent retry storms.
Circuit breaking
failure_accrual circuit breaker takes failing endpoints out of rotation; configure per-route via HTTPRoute / ServiceProfile.
Timeouts
Per-route timeouts via HTTPRoute / ServiceProfile prevent slow upstreams from holding proxy resources.

Sources