API Server Request Calculator
Estimate the request rate hitting the Kubernetes API server from controllers and clients.
About API Server Request Calculator
The kube-apiserver enforces client-side rate limiting via client-go's QPS/Burst settings and, on the server side, API Priority and Fairness (APF) flow-control queues that cap request rate per priority level. Estimating aggregate QPS from client count and per-client request rate helps predict whether a growing number of controllers, CI/CD jobs, or operators will bump into those throttle thresholds and start seeing 429 Too Many Requests responses.
Formula
QPS = (clients × requestsPerClientPerMinute) / 60
- C
- Number of API server clients
- R_c
- Requests per client per minute
- Q
- Aggregate API server QPS
Worked example
With the default values below, API Server Request Calculator returns Estimated API Server QPS of 50.00. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Number of Clientsaccepts 0–1,000,000 clients
- 150 clients
- Requests per Clientaccepts 0–1,000,000 req/min
- 20 req/min
- Throttle Thresholdaccepts 1–1,000,000 QPS
- 400 QPS
Results
- Estimated API Server QPS
- 50.00 QPS
- Utilization vs Throttle Threshold
- 12.5%
- Will Be Throttled
- false
- Headroom Before Throttling
- 350.00 QPS
Step by step
- 1Total requests/min = clients × req/client= 3000 req/min
- 2QPS = req/min ÷ 60= 50.00 QPS
- 3Utilization vs throttle threshold= 12.5%
Assumptions and limits
- The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
What causes API server throttling in practice?
A surge in controllers, operators, or CI/CD pipelines all polling or reconciling against the API server simultaneously — especially list/watch-heavy workloads or clients without exponential backoff on retries — pushing aggregate QPS above the configured flow-control limits for their priority level.
How does API Priority and Fairness (APF) help?
APF classifies requests into priority levels (e.g. workload-high, leader-election, global-default) with separate queues and concurrency limits, so a burst of low-priority traffic can't starve critical system components like the scheduler or controller-manager from getting API server time.
What's the fix if legitimate clients are hitting throttling?
Add client-side caching/informers instead of repeated polling, ensure clients respect Retry-After and use exponential backoff, and if genuinely needed, request an increase to the relevant APF priority level's concurrency share.