When to upgrade the box, and when not to

"Do I need a bigger server" is asked constantly and answered badly, usually by somebody comparing their plan against a table of recommended specifications that was written without knowing anything about their server.

The question has an actual answer, and it comes from four numbers you can measure this afternoon.

The four numbers

Tick time at peak. Not average — peak. If your budget is 50ms and you are sitting at 12ms with forty people on, you have enormous headroom and a bigger box buys nothing. At 45ms you are one popular evening from falling behind.

Memory used at peak, after a full collection. The number that matters is the floor the heap returns to, not the ceiling it reaches. A heap that sawtooths between 3GB and 6GB is healthy at 8GB. A heap whose low point climbs week over week is leaking, and more memory postpones rather than fixes it.

Disk usage and its slope. Not how full it is — how fast it is filling. A disk at 60% that gains a percent a week is a problem with a date on it.

Steal time, if you are virtualised. This is CPU time the hypervisor gave to somebody else while your server wanted it. Above a couple of percent sustained means you are being throttled by neighbours, and upgrading within the same host may buy nothing at all.

Take those four at your busiest hour, not at 3am. That is the entire measurement, and it is what monitoring over days exists to give you.

Upgrade for the one that is binding

Servers are usually limited by exactly one resource, and buying more of the others is wasted money.

If tick time is high and memory is fine, you need faster cores, not more of them: the main loop is single-threaded and more cores do not make one thread quicker. This is the most common misdiagnosis in game hosting, and it is why clock speed matters more than core count for most of what a server does.

If memory is the constraint, more RAM. If the disk is, faster storage or less written to it. If steal time is, a different host rather than a bigger plan.

The cases where a bigger box is the wrong answer

A leak. Doubling the heap doubles the time until the crash. It does not remove it, and it makes each crash more disruptive because the restart takes longer.

Entity accumulation. A server whose tick time climbs over hours and resets on restart is not short of CPU. It is holding too much, and the fix is configuration.

Unbounded exploration. Chunk generation is expensive and pregeneration removes the cost entirely. Buying CPU to generate terrain faster is paying to do work you could have done once, overnight, for free.

Too many things on one machine. If four servers contend, a bigger box helps until you put a fifth on it. A second machine removes the shared failure domain as well, which is the part running several servers together gives up.

Measure before and after, or you learn nothing

The upgrade itself is the easy part. What almost nobody does is record the four numbers on the old plan and take them again a week later on the new one.

Without that comparison there is no way to know whether the money bought anything. Servers routinely move to a larger plan, feel better for a fortnight because the migration also restarted everything and cleared whatever had accumulated, and conclude the upgrade worked: when what actually helped was the restart.

Write the four numbers down before you migrate. It takes two minutes and it is the difference between an upgrade and a purchase.

The threshold worth using

Upgrade when the binding resource is above about 70% at peak and the trend is upward, and when you have ruled out the four cases above.

Seventy rather than ninety, because the gap is your margin for an unusual evening, and because a server that is perfectly sized is a server with no room for the thing that made it popular.

The three upgrades that are usually the wrong one

Before spending money, it is worth knowing which purchase does nothing, because the wrong upgrade is common and expensive.

The first is more cores, for a single-threaded server. Minecraft, Source and most survival titles run their world on one thread. A machine with twice the cores and the same clock speed runs the tick loop at exactly the same rate, and the only thing that improves is your ability to run a second server that will now compete for cache.

The second is more RAM, for a server that is not short of it. Memory that is not being used does nothing. If the heap is not filling and the kernel is not swapping, adding more changes no observable behaviour, and it is the most frequently sold upgrade because it is the easiest number to compare.

The third is a faster disk, for a server that is CPU-bound. NVMe helps chunk loading and world saves. It does not help a tick loop that is busy doing entity logic, and a server stuttering from mob density will stutter identically on the fastest disk available.

The common thread is that all three are upgrades to something that was not the constraint, which is why measuring before buying is worth the evening it takes.

Downgrading is also a decision

Nobody ever checks. A server sized for a peak that stopped happening a year ago is paying for headroom it will not use, and that money is better spent on a second small box for staging, or on nothing at all.

Look at the four numbers once a quarter. If the peak has fallen and stayed fallen, the plan can fall with it, and knowing that is worth more than the saving, because it means you are reading the numbers rather than assuming them, which is the same habit that turns a listing's traffic from a mystery into something you can act on.