Capacity Planning Without a Spreadsheet Habit
12 Oct 2026Capacity planning for a small team doesn’t need a spreadsheet with growth-rate formulas and confidence intervals. It needs three numbers you already have in your monitoring, checked monthly, against one rule of thumb.
The three numbers
Pull these from whatever you already run (Netdata, Prometheus, your host provider’s panel):
- Current peak usage — CPU, memory, and disk at your busiest hour, not the average. Averages hide the moment you actually run out of room.
- Growth rate — how much that peak moved over the last 3 months. Not precise, just “went from 40% to 55% CPU at peak over 90 days.”
- Time to act — how long it takes you to actually respond: provisioning a bigger box, adding a read replica, optimizing a query. For most self-hosted setups this is hours to a couple of days, not weeks.
That’s the whole input. You’re not modeling anything — you’re reading a trend line and comparing it to how much runway you need.
The rule of thumb: 70% and climbing means act now
Don’t wait until you’re at 90% peak utilization to do something. If peak CPU, memory, or disk is consistently above 70% and the trend over the last quarter is upward, start the upgrade now, not when it hits 95%.
70-80% peak, flat trend → fine, recheck next month
70-80% peak, rising trend → plan the upgrade this month
80%+ peak, any trend → act now, you're close to the edge
The reason for 70% instead of some tighter number: self-hosted infra doesn’t scale instantly. A managed cloud service can autoscale in seconds. A VPS resize means downtime or a migration, and disk expansion on some providers takes a support ticket. Leave yourself the lead time your actual process requires.
Disk fills differently than CPU
CPU and memory pressure degrade gracefully — things get slow before they fall over. Disk doesn’t: you have headroom, then you have zero, and the failure mode is often total (database can’t write, logs stop, app crashes). Treat disk more conservatively than CPU — act at 70%, not 80%, and check it more often, because log growth in particular can be non-linear (a bug that suddenly logs at 100x the normal rate fills a disk in hours, not months).
Vertical vs horizontal, and when to switch
| Situation | Move |
|---|---|
| One server, room to grow on the same provider | Resize the VPS (vertical) — simplest, usually a few minutes of downtime |
| Already on the largest practical single-box size | Split by function — DB on its own box, app on another |
| CPU-bound and stateless (web/API tier) | Add a second instance behind a load balancer (horizontal) |
| Disk-bound on a database | Bigger volume first; a read replica only if the bottleneck is read query load, not storage |
Stay vertical as long as it’s viable. It’s less operational complexity than horizontal scaling, and for most small self-hosted setups, “buy a bigger box” solves the problem for another six to twelve months at a fraction of the effort of re-architecting for multiple nodes.
The actual habit
Once a month, look at peak CPU, memory, and disk against the 70% line, and glance at whether the trend over the last quarter is flat or climbing. That’s it — five minutes, and you’re the one deciding to upgrade on your own schedule, not finding out you needed to three weeks ago when the disk filled at 2am.