CPU percentage cannot tell you the capacity left
CPU occupancy can rise while useful throughput stalls. Plan server capacity around latency and completed work, with utilization as supporting evidence.
By 
Paul. Architecture and infrastructure
A server showing half its CPU capacity in use does not necessarily have room for twice the customer traffic. CPU utilization describes time accounted as busy within a particular measurement system. It does not directly measure the fraction of useful work the machine can still deliver. Capacity decisions need completed requests, acceptable latency and failures alongside that percentage.
Looking back from November 2026, Brendan Long's 2 September 2025 article made the distinction unusually visible. His experiments compared reported utilization with work completed under several workloads. They are evidence from his machine, not measurements of an AL+ application or a universal conversion table between CPU percentage and spare capacity.
The denominator deserves attention
Imagine an illustrative service whose monitoring graph stays comfortably below its alarm threshold while customers wait longer. Buying capacity only when the graph crosses a round percentage could miss the problem. Equally, buying a larger server whenever utilization rises could waste money if completed work rises proportionately and customer latency stays acceptable. The graph needs an operational question before it supports a purchasing decision.
Start by identifying what the monitor counts. Host averages, process percentages and container limits can use different denominators. A process percentage spanning several logical processors can exceed the familiar single-processor scale. An average can also hide one saturated execution path while other processors remain idle. These accounting choices describe different things; none automatically answers how many orders the service can accept.
As Brendan Gregg explained in his 9 May 2017 account of CPU accounting, scheduled execution can include periods when a core waits for data from memory. Being scheduled does not mean executing a useful application instruction on every cycle. Conversely, waiting for external input may leave CPU idle even though the service is already constrained elsewhere. This is why a utilization percentage cannot diagnose either the cause of a slow request or the amount of remaining useful work by itself.
Shared resources change the curve
Long's matrix workload reached its useful ceiling around the point where half the machine's logical processors were occupied. He explains the result through simultaneous multithreading: logical siblings share physical execution resources. His general CPU workloads behaved differently. His article also discusses changing processor frequency as more cores become active. Those qualifications belong beside the result, rather than beneath a promise that every machine saturates at the same percentage.
The capacity-planning implication is about the shape of the curve. Additional scheduled workers may add useful throughput, add progressively less, or create contention. The outcome depends on which resources the workload needs. A logical processor is a scheduling opportunity, not an independent duplicate of all the physical resources behind it. Turning the logical count into a linear business forecast silently assumes away that distinction.
Frequency adds another moving part. A short burst with a few active cores need not run at the same frequency as sustained activity across the processor. Power and thermal constraints can change the work delivered per unit of scheduled time. A stable percentage on a changed machine or after a changed workload is therefore weaker evidence than it first appears. No fixed correction factor repairs all these relationships.
Write the capacity claim in customer units
A useful capacity statement names the work and its conditions: a defined mix of requests, a latency target, an acceptable error level and a period long enough to expose relevant limits. This is a proposed measurement contract, not a benchmark performed here. The contract should reflect the costly operation customers actually perform, including downstream dependencies that constrain completion.
Separate offered load from completed work. If requests accumulate in a queue, arrival rate can increase while completion rate stays flat. Calling that growth in demand handled would conceal the backlog. Tail latency matters because an acceptable average can coexist with a group of customers experiencing long delays. Include timeouts and rejected work rather than treating them as absent observations.
Compare like conditions before drawing a trend. Record the application revision, hardware allocation, workload mix and relevant resource limits. A change in payload size or the proportion of expensive operations can change throughput even when request counts look stable. A capacity envelope is conditional on these inputs; it is not a permanent property attached to a server model.
Keep the cheap signal
The strongest argument for CPU-based planning is practicality. Utilization is inexpensive to collect, widely available and often correlates well with traffic for an unchanged workload on unchanged hardware. A team with a known operating history can use that relationship to trigger investigation or scale ahead of a familiar peak. Discarding it would remove useful evidence.
The boundary is extrapolation. A correlation within the observed range does not establish a linear relationship beyond it, especially across shared-resource or frequency changes. Use utilization as an early indicator and diagnostic context. Tie the decision to customer-facing completion and latency before claiming that a particular amount of additional traffic will fit.
For custom software development, that means agreeing on the capacity question while the service is designed. Decide which work must finish on time and who will revisit the evidence when the workload changes. A CPU alarm can tell someone to look. A defensible capacity claim explains what the service can deliver and the conditions under which that remains true.