Every host advertises it, every comparison table has a column for it, and almost every argument about it is people talking past each other. Tick rate is worth understanding precisely, because the number is real: it is just answering a narrower question than most people think.
The simulation clock, and nothing else
A dedicated server runs a loop. Each pass through that loop it reads the inputs that have arrived, advances the physics and game logic by one time step, and resolves what happened. One pass is a tick. Tick rate is how many of those it performs per second.
That is the whole definition. It says nothing about how often the server sends you an update, nothing about your framerate, and nothing about your ping.
The confusion is understandable, because in the simplest possible architecture those things are the same number. Most engines have not been that simple for a long time.
Send rate is a different number
Simulation frequency and network update frequency are usually decoupled, and often deliberately different. A server can advance its simulation frequently while sending each client a snapshot less often, because bandwidth scales with players squared in the worst case and simulation does not.
This is why "tick rate" as a marketing figure is slippery. A host quoting a simulation rate and a host quoting a snapshot rate are quoting different things, and neither is lying. When the two are decoupled, the one that governs how current your view of the world is, is the send rate.
What it costs
Doubling the tick rate roughly doubles the simulation work per second. It is not exactly linear (some per-tick work is fixed overhead and some scales with what is actually happening in the world), but linear is the right mental model for capacity planning.
The important part is where that cost lands. Game simulation is difficult to parallelise, because a tick is a sequential dependency: you cannot compute tick N+1 until tick N has resolved. Most engines therefore run the main simulation on one thread. Extra cores help with everything around it (networking, asset streaming, other server instances on the same box), but they do not help the simulation loop go faster.
The practical consequence is that single-core performance is the specification that matters for a game server, and it is the one most hosting comparisons bury under total core count. A box with many slow cores will host more instances and run each of them worse.
When raising it does nothing
Here is the part that saves people money.
If players report rubber-banding, hit registration disputes, or players warping around corners, the instinct is to raise the tick rate. Usually that is the wrong lever, because those symptoms are dominated by three other things:
- Network latency and jitter between the player and the server. No simulation frequency compensates for a variable path.
- Interpolation and lag compensation: how the engine reconciles what a player saw with what the server believes. These are engine behaviours, often configurable, and they set the felt responsiveness far more than tick rate.
- Whether the server is actually hitting its configured rate. A server configured for a high rate and missing it under load behaves worse than one configured lower and hitting it consistently, because the interval becomes irregular rather than merely long.
Point three is the one worth checking first, and it is measurable. Before changing any configured value, find out what the server is actually achieving during a busy period. Most dedicated servers expose this, and the gap between configured and achieved is the entire diagnosis.
The useful version of the question
"What tick rate should I run" is not answerable in the abstract. "Is my server sustaining its configured tick rate with a full player count, and if not, is it CPU-bound on one core" is answerable, and the answer tells you whether to change a setting or change a machine.
That is a less satisfying number to put in a comparison table. It is the one that determines whether the server feels good to play on.