---
title: Capacity planning lessons from hosting at scale
description: "What running large hosting fleets taught me about capacity: plan on percentiles, watch for growth cliffs, and price headroom against outages."
date: 2026-06-01
updated: 2026-06-01
tags: [hosting, practitioner]
url: "https://joshdargie.com/blog/capacity-planning-hosting"
author: Josh Dargie
---

I spent years doing capacity planning for shared hosting fleets, the kind of environment where thousands of customers share hardware and every planning mistake is public. Most of what I learned transfers directly to anyone running infrastructure, whether that is a SaaS platform or three servers behind an agency.

Here are the lessons I keep reusing.

## Averages are how you lie to yourself

The first mistake everyone makes is planning on averages. Average CPU is 30 percent, so we have lots of room, right?

No. Nobody experiences the average. Your customers experience the peaks, and capacity problems live entirely in the tail. A server that averages 30 percent but hits 95 percent every weekday at 10 a.m. is a server with a capacity problem, full stop. The average is telling you a soothing story about the other 23 hours.

Plan on percentiles. Look at the 95th and 99th percentile of CPU, memory, disk I/O and connection counts over a realistic window, at least a month, so you catch the weekly and month-end patterns. In hosting we sized to the busy hour, not the day, because billing runs, cron storms and marketing sends all cluster. Whatever your equivalent of the busy hour is, that is the number you plan against.

The second half of this lesson: watch the trend of the percentile, not the level. A p95 that climbed from 60 to 75 over two quarters is more alarming than a flat 80, because it tells you where you will be in two more.

## Growth is smooth until it is a cliff

Resource usage grows gradually. Costs do not. Costs go up in stairs, and the steps are where planning fails.

A database fits in memory until it does not, and the day it stops fitting, performance does not degrade 2 percent, it falls off a cliff, because you have swapped a memory workload for a disk workload. The same shape shows up everywhere: the last drive bay in the chassis, the rack that has no more power, the licence tier that jumps at the next increment, the application that runs beautifully on one server and needs real re-architecture to run on two. I saw that last one constantly at scale, and wrote about a related version of it in [running cPanel at scale](/blog/cpanel-at-scale).

The planning discipline is to know where your next three cliffs are and how far away each one is at current growth. Not precisely, roughly. "We are about two quarters from the database not fitting in RAM" is an actionable sentence. The cliffs you map in advance are engineering projects; the ones you discover at 2 a.m. are incidents.

Lead time matters more than people think. Hardware, network upgrades, and any migration involving customer data all take longer than the spreadsheet says. If you start solving a cliff when you hit it, you are already late.

## Headroom is insurance, and insurance has a correct price

Every dollar of spare capacity is a dollar spent on nothing, until the day it is the only thing that matters. So the real capacity question is an insurance question: how much are you paying for headroom, and how much would the outage cost?

Both numbers are estimable, and almost nobody estimates them. Headroom cost is easy: the monthly price of the capacity above your p99. Outage cost is revenue per hour, plus refunds or SLA credits, plus the churn that follows a bad week, plus the engineering month you lose to recovery. When I actually ran these numbers in hosting, headroom in the 30 to 50 percent range above busy-hour peak usually priced out as cheap insurance, because one bad multi-hour outage cost more than a year of the spare capacity.

But the answer is not "more headroom" universally. An internal reporting system that can be slow on the last day of the month does not deserve the same insurance as your checkout path. Tiering headroom by what the outage actually costs is where the savings come from.

One warning from the fleet years: measured headroom is not the same as usable headroom. Capacity you cannot fail into, because it is in the wrong place, or because the failover has never been tested, is a number on a dashboard, not insurance.

## The habit that matters more than the math

None of this requires sophisticated tooling. It requires a recurring calendar entry: once a month, look at percentile trends, update the distance to the next cliff, and sanity-check the insurance math. Capacity planning fails as an annual event and works as a boring habit.

If you run infrastructure and want an outside set of eyes on your capacity position, that is work I do on a fixed-fee or retainer basis. The place to start is [my hosting and infrastructure page](/hire#hosting).