Game Server Tick Rates: What 20, 30, and 60 Ticks Per Second Mean

“20 tick”, “30 tick”, “60 tick” — you see these numbers on every game server config and hosting spec sheet, but what do they actually mean for your players? Tick rate is the number of times per second the server computes the world state, and it determines the precision of everything from hit registration to fall damage. Here is what 20, 30, and 60 ticks per second mean in practice, and how much CPU each one costs you.

What a tick actually is

Game servers do not run a continuous simulation; they process the world in fixed timesteps called ticks. Each tick, the server evaluates movement, physics, AI, block or world changes, and combat. The client renders between ticks using interpolation, which smooths the picture — but the server’s tick rate still sets the ceiling on how precisely it can detect hits, landings, and collisions. A 20-tick server makes decisions every 50 ms; a 60-tick server every 16.7 ms — three times finer.

Tick rate defaults by game

Game	Default tick rate	Tick interval	Notes
Minecraft (Java)	20 TPS	50 ms	Fixed in vanilla; mods can raise it
Valheim	20	50 ms	Fixed
Terraria	60	16.7 ms	Fixed
ARK: Survival Ascended	30	33.3 ms	Configurable via MaxServerTickRate
Palworld	30	33.3 ms	Fixed
Rust	30	33.3 ms	server.tickrate setting
Counter-Strike 2	64 (128 community)	15.6 / 7.8 ms	-tickrate launch argument

What 20 vs 30 vs 60 feels like

At 20 ticks per second, movement checks and hit windows update every 50 ms. That is fine for survival and building games, where combat is forgiving and precision matters less than world persistence. At 30 TPS (ARK, Palworld, Rust) the world feels tighter, and melee and projectile combat behave noticeably better. At 60 TPS the server resolves actions three times as often as a 20-tick server — the difference players notice in shooters as cleaner hit registration, fewer “I was behind the wall” deaths, and less rubber-banding on jump and movement.

There is a catch: tick rate only fixes server-side precision. If your players have high ping or packet loss, no tick rate fixes that. But a low tick rate amplifies network problems, because the server is making coarser decisions about what it received.

Competitive shooters push this further. Counter-Strike 2’s official servers run at 64 ticks and community servers at 128 — hit registration and grenade physics are tuned around the finer simulation step. At 128 ticks the server resolves actions every 7.8 ms, which is why high-skill players insist on 128-tick servers for scrims. That precision costs CPU: a 128-tick server needs roughly double the tick-processing power of a 64-tick one.

Tick rate is a CPU problem, not a RAM problem

Each tick runs the entire simulation, so the cost of a higher tick rate is CPU time, and it scales almost linearly: a 60-tick server needs roughly three times the tick-processing power of a 20-tick one. RAM handles world size, entities, and player count; the CPU handles tick speed. This is why you can throw 32 GB at a laggy Minecraft server and see no improvement — the bottleneck is the tick thread, not memory.

Measure, don’t guess. On Minecraft, /tps shows ticks per second and the Spark profiler shows per-tick time; a healthy server at 20 TPS averages 10 ms or less per tick, leaving 50% headroom for spikes. On Rust, the server console reports server FPS, which is the tick rate in practice. If average tick time approaches the tick interval (50 ms at 20 TPS, 33.3 ms at 30, 16.7 ms at 60), your CPU is saturated and players will feel it.

A concrete example: a vanilla Minecraft server with 40 players typically spends 8-15 ms per tick on a modern 8-core CPU — fine at 20 TPS with plenty of headroom. Push the same world onto a 2014-era Xeon and per-tick time can double, tipping the server below 20 TPS during peak hours. The same logic applies at every tick rate: your CPU must finish each tick inside its interval, or players experience it as lag, stutter, and failed hit registration.

Raising the tick rate on common servers

• Minecraft: vanilla is fixed at 20 TPS. Server-side mods such as TickrateChanger can raise it, but physics and redstone assumptions break above 20 — most large servers stay at 20 and optimize tick time instead.
• ARK: Survival Ascended: set MaxServerTickRate=60 in GameUserSettings.ini (default is 30). CPU load rises with it.
• Rust: server.tickrate 30 in server.cfg; the engine is tuned around 30, so higher values cause physics issues.
• Source games / CS2: launch the server with -tickrate 64 or 128; 128 doubles the per-tick CPU load of 64.

Buying for tick rate: clock speed first

Because tick processing is single-threaded in most engines, buy the fastest single-core performance you can afford, then cores for player count and multi-instance hosting. A modern 8-core with a 5+ GHz boost runs a 20-tick survival server with huge headroom, while a 60-128 tick shooter server wants the absolute best single-thread CPU in your budget. If you are comparing configurations, compare dedicated server plans and rent a dedicated server for game hosting with a CPU that matches the tick rate you intend to run.

Bottom line

Tick rate is the heartbeat of your game server: 20 for survival and building games, 30 for action-survival titles, 60+ for competitive shooters. It costs CPU time, not RAM, and it is the first thing to check when players report hit registration or rubber-banding. Set the right tick rate for your game, watch your per-tick times, and size the CPU accordingly — the dedicated server hardware options guide covers the rest.