English for Capacity Planning: Talking About Scaling and Headroom
Vocabulary and phrases for capacity planning in English: headroom, saturation, forecasting, scaling, and how to present capacity risk and proposals to your team.
Capacity planning is the work of making sure your systems can handle future load — before they fall over. The conversations involve forecasting growth, measuring how full things are, and deciding when to scale. The English is a mix of measurement vocabulary (saturation, headroom, utilisation) and persuasion (justifying spend on extra capacity). This guide gives you both.
Core vocabulary
| Term | Meaning |
|---|---|
| Capacity | The maximum load a system can handle |
| Headroom | Spare capacity before you hit the limit |
| Utilisation | How much of capacity is currently used (%) |
| Saturation | How full / overloaded a resource is |
| Bottleneck | The component that limits the whole system |
| Scale up / out | Add power vertically / horizontally |
| Forecast | A projection of future demand |
“We’re running at 70% utilisation, so we’ve got some headroom, but the database is the bottleneck — it saturates first.”
Headroom (spare margin) is the single most useful word in capacity discussions. You “have headroom,” “run out of headroom,” “build in headroom.”
Scale up vs scale out
These are different and often confused:
- Scale up (vertical) — make a machine bigger (more CPU/RAM)
- Scale out (horizontal) — add more machines
“We can scale up the database to buy time, but long term we need to scale out with read replicas — a single box has a ceiling.”
The word ceiling (the maximum possible) pairs naturally: “we’re hitting the ceiling on vertical scaling.”
Describing how full things are
Use percentages and precise verbs for load.
- “CPU is sitting at 60% on average.”
- “Memory peaks at 90% during the nightly batch.”
- “We max out connections at 200.”
- “Traffic doubles during the campaign.”
- “We’re comfortably within capacity.”
“Day-to-day we sit at about 50% utilisation, but during peak we spike to 85%. That leaves thin headroom for an unexpected surge.”
The contrast between average load and peak load is central — you plan for peak, not average.
Forecasting language
Capacity planning is about the future, so you need the language of projection and uncertainty.
- “If growth continues at this rate, we’ll hit capacity by Q3.”
- “Based on the trend, we’re on track to saturate in about ten weeks.”
- “Assuming the launch doubles traffic, we’ll need 40% more capacity.”
- “There’s a lot of uncertainty in this forecast.”
“Extrapolating the current trend, we run out of headroom around October. If the product launch lands, that pulls forward to August.”
Pull forward (make something happen sooner) and push out (delay) are useful for shifting timelines: “the launch pulls the deadline forward.”
Presenting capacity risk
The hard part is convincing people to spend on capacity before there’s a problem. Make the risk concrete.
| Vague | Concrete |
|---|---|
| ”We might run out." | "At current growth, we hit the connection ceiling in ~6 weeks — that means checkout failures." |
| "We need more servers." | "Adding two replicas buys us six months of headroom for about £400/month." |
| "It could get slow." | "Past 85% utilisation, latency degrades sharply — we’d breach our SLO.” |
“Here’s the risk in plain terms: at today’s growth we run out of headroom in six weeks. When we saturate, latency degrades and we breach SLO. The fix is two replicas — modest cost, six months of runway.”
Runway (how long until you hit a limit) is excellent capacity vocabulary, borrowed from startups.
Proposing a plan
Frame proposals as options with trade-offs, not demands.
“We’ve got three options. Scale up the primary — quick, but only buys a month. Scale out with replicas — more work, six months of headroom. Or optimise queries — cheapest, but uncertain payoff. I’d lean toward the replicas.”
Phrases:
- “I’d lean toward option B.”
- “The cheapest option buys us the least time.”
- “This is a stopgap, not a real fix.”
- “Let’s build in 30% headroom for safety.”
Stopgap (a temporary measure) is a precise, professional word for a quick fix that isn’t the real solution.
Before and after: a full rewrite
Before (vague, alarmist or too quiet):
“the servers are getting full and maybe we will have problems later, we should buy more servers I think, it could be bad if traffic grows.”
After (quantified, framed, decisive):
“Capacity check: we’re at 70% utilisation on the database, the system bottleneck. Peak hits 85%, leaving thin headroom. Extrapolating current growth, we run out of runway in about six weeks — at which point we’d saturate and breach our latency SLO. My recommendation is to scale out with two read replicas: roughly £400/month, buys ~six months of headroom. Scaling up the primary is a faster stopgap but only buys a month. I’d lean toward the replicas.”
Common mistakes
- Confusing “scale up” and “scale out.” Up = bigger machine; out = more machines. Mixing them confuses the architecture.
- Planning for average instead of peak. Always design around peak load plus headroom.
- Saying “capacity is full.” Better: “we’re at 90% utilisation” or “running low on headroom.” “Full” is binary and imprecise.
- Confusing “saturation” and “utilisation.” Utilisation is the percentage used; saturation is the degree of overload (queueing, contention). High utilisation leads to saturation.
- Forecasting without uncertainty. Always acknowledge “this assumes growth continues” — false precision erodes trust.
Mini-glossary
- Load testing — simulating traffic to find limits
- Throughput — work done per unit time
- Provision — allocate resources in advance
- Over-provision / under-provision — too much / too little capacity
- Elastic / autoscaling — capacity that adjusts automatically
- Demand — the load placed on the system
- Peak / off-peak — busiest / quietest periods
“If we move to autoscaling, we stop manually provisioning for peak and pay only for the demand we actually see.”
Key takeaways
- Headroom and runway are your two key framing words — spare margin and time-until-limit.
- Distinguish scale up (bigger) from scale out (more), and utilisation from saturation.
- Plan for peak, not average, and always build in headroom.
- Present risk concretely (weeks of runway, cost, SLO impact) and offer options with trade-offs, flagging stopgaps.
Capacity planning is forecasting plus persuasion. Quantify the runway, name the bottleneck, and propose options — and you’ll get the resources before, not after, things break.