*Published July 11, 2026* --- Ask an engineering team how much more traffic their service can take, and the answer usually comes back as a resource number. CPU is at forty percent, so there is room. Memory looks fine. The database is quiet. John Allspaw, who ran Flickr's infrastructure and wrote *The Art of Capacity Planning*, documents both ways that answer fails: photo servers hitting intolerable time-to-serve while every gauge stayed healthy, and the reverse, a disk filling quietly until a service that looked fine at breakfast is down by lunch. Both failures have the same root: the resource number says nothing about whether the service is keeping its promises. ## One driver, three ceilings Google's SRE book names [four golden signals](https://sre.google/sre-book/monitoring-distributed-systems/) for any user-facing system: latency, traffic, errors, saturation. They are not equals for capacity planning: traffic is the driver you forecast; the other three are ceilings. - **Latency** breaks when response time crosses the SLO you promised. - **Errors** break when the failure rate burns past the error budget. - **Saturation** breaks when a resource crosses its red line: queue length and wait time, per Brendan Gregg's [USE method](https://www.brendangregg.com/usemethod.html), not percent busy. For cliff-type resources like disk fill it is the only warning you get. Capacity is the lowest traffic level at which any of the three gives way; the distance between current traffic and that point is the real headroom. The number arrives with a label, and the label is the useful half. Saturation breaking first names the resource to expand. Latency or errors breaking first means more hardware may buy nothing; the problem lives in the architecture or the promise itself. Even then the label buys a narrower search, not the fix: Allspaw's example is slow pages that trace to page construction, which no capacity purchase repairs. The set has a blind side: these are the best four, not the only things that break. A downstream dependency's quota can give way first and read as false headroom; off-axis promises need their own red lines. ## You cannot calculate it No break point comes from a spec sheet; ceilings are found by driving real load. - **Allspaw**, *The Art of Capacity Planning*: red lines are observed, not derived; Flickr confirmed them by pulling servers from the live pool so the rest absorbed more production traffic. - **Michael Nygard**, *Release It!*: the true capacity proof is the seasonal production peak, which brings a changed request mix, not just more volume. - **Google's SRE book**: services go nonlinear near overload; you cannot trend a healthy curve into the saturation zone. - **Roberto Vitillo**, *Understanding Distributed Systems*: at saturation, raw throughput lies. Count goodput, the requests that both succeed and return in time. ## Two boundaries the definition has to respect Before writing this down I went looking for the strongest evidence against it. Two findings survive, plus a smaller qualifier. First, a break point only exists in the stable regime. Research on [metastable failures](https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s11-bronson.pdf) (Bronson et al., HotOS '21; [OSDI '22](https://www.usenix.org/system/files/osdi22-huang-lexiang.pdf)) shows a temporary trigger can drop a system into a self-sustaining degraded state: retries multiply load, caches run cold, and it stays broken at traffic it handled the day before. In the [October 2025 AWS incident](https://aws.amazon.com/message/101925/), EC2 kept failing roughly eleven hours after its DynamoDB trigger was fixed. A smooth-ramp ceiling is an upper bound, valid only while no feedback loop is in play. Second, the latency break point is optimistic if you measure it the default way. Gil Tene's [coordinated omission](http://highscalability.com/blog/2015/10/5/your-load-generator-is-probably-lying-to-you-take-the-red-pi.html): closed-loop load generators wait for each response before sending the next, so just when the system slows down they sample it less. A p99 only means something if the generator is open-loop or measures against intended send times. The smaller qualifier: under autoscaling you measure one scaling unit's ceiling; the service limit becomes the control loop's reaction time and cost. ## The loop 1. Fix the red lines first: the latency SLO, the error budget, the per-resource saturation lines. 2. Drive real load, or shift live traffic, and record each ceiling signal as a function of traffic, holding the request mix constant. 3. Find each break point. Take the last stable crossing; warmup transients understate the ceiling. 4. Take the minimum, and name the signal that set it. 5. Report headroom against forecast traffic, with the label. Re-measure after every meaningful change; adding capacity moves the bottleneck. Step 1 needs no tooling: write the red lines down. A team that cannot state them meets them for the first time during an incident. ## Where this leaves me Everything above comes from reading, not from an incident: four operations books read against each other, plus the two papers that pushed back hardest. I have not yet load-tested a service and come away with three break points and the name of the one that bound. Until that happens, this definition is a claim waiting for its first real test. The reading did change what I ask for. A capacity answer now has to name the latency SLO, the error budget, the resource red lines, and the traffic level where one of them was last seen to break. If no one can say, finding out is the first piece of capacity work.