Principle
Keep headroom for variability and recovery
Slack looks inefficient until the first spike, outage or slow task arrives.
When it fits
- A system or team is planned to run near its measured maximum because idle capacity feels wasteful.
When to avoid it
- Too much reserved capacity has real cost; choose headroom from observed variability and recovery needs.
Why it matters
Set normal operating load below the breaking point by a margin justified by demand variability, failure recovery and scaling delay. Watch sustained utilization rather than celebrating maximum occupancy. Headroom buys time for bursts and degraded capacity without immediately entering overload feedback.
An example
Do not schedule every agent worker at 100% concurrency if one slow external API can double job duration and fill the queue.
Check your result
Normal operation can absorb a plausible spike or partial capacity loss without immediate collapse.
Keep this limit in mind
- Too much reserved capacity has real cost; choose headroom from observed variability and recovery needs.
Evidence and sources
Google SRE notes that high utilization with little headroom can create cascading overload when capacity is lost or demand rises.
The appropriate safety margin depends on variability, recovery time and cost.
Addressing Cascading Failures · Server overload and resource exhaustion