Throughput (request rate)
How much work a system handles per unit of time, such as requests per second or jobs per hour.
See it
What it is
Throughput is how many operations a system handles per unit of time, usually requests per second, messages per minute, or jobs per hour. For a request-driven service it is also called request rate. Count completed operations with a monotonically increasing counter, then calculate how fast that counter moved over a window.
Reach for throughput to size capacity, spot traffic changes, and read latency in context. It is the R in the RED method (rate, errors, duration), Tom Wilkie's request-side companion to the golden signals. A service doing 100 requests per second at 50ms is a different situation from one doing 10,000 at the same latency, and Little's Law connects throughput, time in the system, and the amount of concurrent work.
Gotcha: an average rate smooths away the burst that exhausted the pool. Chart both a short and a long window, and be explicit about whether you count accepted, started, or completed operations. Throughput is not capacity either: the current rate says what the system handled, not the maximum it can handle safely.
Ask AI for it
Add a Prometheus Counter named http_requests_total that increments once for every completed request and uses only method, route, and status_class labels. Create PromQL panels for rate(http_requests_total[1m]) and rate(http_requests_total[15m]), show requests per second by service and route, and place p95 latency and in-flight requests beside them. Add a load test with k6 that steps through increasing request rates and marks the point where p95 latency exceeds 500ms or the error rate exceeds 1 percent.