Tick Rate
Tick rate is how many times per second a game server recalculates the state of the match, measured in hertz. On every tick it processes inputs, advances the simulation and sends an update. A higher rate means finer time resolution for hit registration and movement, and more CPU consumed per server.
Also called
tickrate; server tick rate
,
What Happens Inside a Single Tick?
Tick rate sets a deadline. Divide 1,000 milliseconds by the rate and you have the window the server gets per cycle. At 20 Hz that window is 50 milliseconds. At 128 Hz it is 7.8.
Everything the server owes the match has to fit inside it: collect the inputs received since the last tick, advance the physics simulation, resolve hit detection, and broadcast the new state to every connected client. Finish early and the server idles until the next tick comes due. Finish late and the tick slips, so the clients waiting on it get an update that arrived when it was ready rather than when it was scheduled.
That deadline is not a fixed amount of work. The same 64 Hz budget is a different job on a host with a slower base clock, or on a server holding 100 players instead of 10. A tick rate is a commitment to hit a deadline under conditions that keep moving.
In Practices - Insights from Edgegap's Blog
Article's key insights
Tick Rate Is a Cost Decision: In Competitive games, tick rate carries a significant CPU load and bandwidth cost, making tick rate one of the most consequential infrastructure choices in multiplayer development given its cost while having a significant impact on players experience of the game's "feel".
VALORANT's Commitment to 128 Hz: Riot rebuilt core engine systems from the ground up to get from a 50ms server frame time to under 2ms. A years-long engineering investment most studios cannot easily replicate.
CS2's Subtick System: Rather than increasing tick rate, Valve introduced microsecond timestamping of player actions, addressing the quantization problem without multiplying infrastructure costs.
Marathon's Middle Ground: Bungie's extraction shooter demonstrates that the right tick rate depends on genre requirements and operational capacity, not just on what the highest number is.
No Universal Answer: Apex runs at 20 Hz, VALORANT at 128 Hz, CS2 at 64 Hz with Subtick, and Marathon at 60 Hz. Each reflects a different balance of precision requirements, player expectations, and what the studio can sustain.
How Does Tick Rate Fit Into a Game's Netcode?
Netcode is the set of techniques that keep separated machines agreeing about one simulation. Tick rate is the clock all of them run on.
Follow a single input. A player pulls the trigger. Their client acts on it immediately so the shot feels instant, which is prediction. The input travels to the server and waits there for the next tick. On that tick the server takes every input that arrived since the last one, resolves them together, and broadcasts one new state to everyone.
That last step has a consequence most tick rate arguments skip. Inputs landing inside the same tick are resolved as though they happened at the same instant. At 64 Hz, two players who fired 4 milliseconds apart are simultaneous as far as the server is concerned, unless the server records when each input actually arrived.
The rest of the netcode stack inherits the same unit:
Client-side prediction extrapolates forward from the last state received, so the tick interval sets how far ahead it has to guess before a correction lands.
Interpolation draws remote players between two received states, which means it runs deliberately behind live by a buffer usually measured in one or two tick intervals.
Lag compensation rewinds the world to what the shooter was seeing, and the finest it can rewind to is a tick.
Change the rate and all three budgets change at once. That is why tick rate is an architecture decision rather than a tuning knob.
What Tick Rate Do Shipped Games Actually Use?
Game | Tick rate (official, or estimated) |
|---|---|
VALORANT | 128 Hz |
Marathon | 60 Hz |
Counter-Strike 2 | 64 Hz with subtick |
Hunt: Showdown | 30 Hz |
Apex Legends | 20 Hz |
ARC Raiders | 20 Hz |
Escape from Tarkov | 12 to 16 Hz |
The spread is wider than the argument around it suggests. Tarkov ships in the 12 to 16 Hz range and Apex at 20, and both hold large, paying, competitive audiences. A low rate is a constraint players feel in specific moments, not a defect.
Counter-Strike 2 is the case worth studying. After years of player demand for 128 Hz servers, Valve did not raise the rate. It timestamped player actions to the microsecond and left the update frequency at 64. An input that used to be rounded to the nearest tick now carries when it actually happened. That decouples input precision from update frequency, which is the more useful of the two to improve and costs far less to run.
What Does a Higher Tick Rate Cost?
Roughly, doubling the tick rate doubles both CPU load and bandwidth consumption.
Bandwidth is the half teams forget. Egress runs 20% to 30% of cloud hosting spend, and tick rate multiplies it linearly for every connected player, so a rate increase that looked like a compute decision arrives as a transfer bill.
Respawn published its reasoning for Apex Legends in plain terms: 20 Hz servers produce about five frames of delay and 60 Hz servers produce three, so tripling bandwidth and CPU cost buys back two frames. They judged that trade not worth making for their game. Riot judged the opposite for VALORANT. Both decisions are defensible, which is the point.
There is no formula that returns the right number. Each tier carries its own cost and its own return, and the return curve flattens well before the cost curve does. Our full breakdown of tick rate against infrastructure cost works through what each step up actually buys.
A word from our sponsor (ourselves!)
A match isn't fair when one player lives next to the datacenter. Edgegap's Edge Cloud draws on up to 615+ distributed locations on demand, placing each server based on where every player in the match connects from rather than in a fixed region. In Edgegap's 1v1 study, that narrowed the fairness gap between opponents by 28%.
Why the Hz a Studio Announces Is a Ceiling
A published tick rate is a target. What matters in play is how often the server hit it.
Riot's work on VALORANT makes the gap visible. Cutting server frame time from 50 milliseconds to under 2 took sustained engineering, and the figure Riot reported afterwards was not 128 Hz. It was that 99.3% or more of server frames met the 128 Hz budget following patch 5.07. The headline is the rate. The disclosure is the percentage.
That percentage drops when servers contend for CPU, which is why a rate that holds in testing degrades at peak concurrency. A server advertised at 64 Hz and delivering 44 under load is worse for the client than one holding a steady 30, because prediction calibrates against a rythm and cannot calibrate against a moving one.
Tick rate and placement spend the same budget from opposite ends. The rate decides how often state is sent. The distance decides how long it takes to arrive. Placement is usually the cheaper of the two to improve: independent replays of studio traffic measured a 58% average reduction in round-trip time for dedicated server placement against public cloud (platform data, as of 18 September 2026).
Edgegap's Take (just our opinion, take it with a grain of salt!)
Tick rate is a moving target, and that's OK
Every studio and every hosting provider will tell you a tick rate. Almost none will tell you what share of ticks met budget at peak concurrency, and that second number is the one that decides whether your netcode has anything stable to work against.
Riot is the exception, and it is telling that earning the right to publish 99.3% took a rebuild.
,
