Capacity planning
Running out of capacity is rarely a surprise in hindsight. The graph was there; nobody was looking at it.
Trend four numbers, monthly
- Peak CPU at your busiest hour, not the average.
- Memory in use excluding cache — the
available figure from
free -h. - Disk: space and IOPS. Space is easy to see coming; IOPS creeps up and then stops being enough all at once.
- Peak bandwidth, in bits per second at the ninety-fifth percentile of your own graph.
Record them once a month in a spreadsheet. Three months of that beats any monitoring dashboard for this particular question, because you are looking at the slope rather than the current value. See Prometheus and Grafana for collecting them automatically.
Order at 70%
A sensible rule: when a resource is consistently above 70% at peak, start the conversation. Above 85% you are in the zone where a normal fluctuation becomes an incident, and where you have no room to absorb a failure.
That leaves time for the thing that actually takes time, which is not us.
Lead times, honestly
- A standard dedicated server
- Usually within the hour, because we assemble from stock we hold.
- An unusual specification
- Days, if a part has to come in. Tell us early and we can hold stock.
- More memory or disks in an existing machine
- A short maintenance window, scheduled with you — see upgrading or changing your server.
- A faster port
- A card swap and a switch port change; coordinated on our side.
- Colocation space and power
- Weeks, sometimes. Power is the resource in a rack that genuinely runs out, and it is the one people assume is infinite.
- Your own migration
- Longer than all of the above. This is nearly always the real constraint — see planning a migration window.
Know which resource will run out first
Every machine has one. Find it before it finds you: a database usually runs out of IOPS or memory, a web front end runs out of cores, a delivery server runs out of port. Adding the wrong thing is expensive and changes nothing — see diagnosing a slow server and how much server do you actually need.
Plan for the week, not the year
Annual growth is easy. What catches people is the predictable spike: a launch, a sale, a seasonal peak, a campaign. Those are known weeks in advance and almost never communicated to the provider.
Tell us. We would far rather know that your traffic will quadruple next Thursday than discover it on Thursday — and on an unmetered port it costs you nothing extra anyway.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base