Server Tick Rate Explained: What It Really Means

Somewhere in every multiplayer game there is a loop that never stops turning. It gathers up what all the connected players have asked to do, works out what happens next, and writes down the result. Then it does it again. Each turn of that loop is a tick, and the number of times it happens per second is the tick rate. That is the whole idea. Everything else that gets argued about on forums, in Discord servers and in server browsers is a consequence of this one design decision, and most of the arguments happen because people are quietly talking about three different numbers while believing they are talking about one.

A tick is a slice of simulated time

Your computer does not know what "smooth" means. It knows how to do arithmetic very quickly, and a game world is arithmetic. Where is this player, what velocity are they carrying, does the line between the muzzle of their weapon and the point they aimed at intersect anything solid, has the grenade's fuse run out. A server cannot answer those questions continuously, because continuous means infinite, and infinite is not a budget you can buy. So it chops time into slices and answers them once per slice.

Between two ticks, nothing happens on the server. Not "nothing much" — nothing. The world is frozen in the state the last tick left it in. Your input arrives, sits in a queue, and waits its turn. When the next tick fires, the server reads the queue, applies physics, resolves collisions, decides who shot whom, and broadcasts the outcome. That waiting period is the fundamental granularity of the game. If you press fire in the middle of a tick interval, the server does not know about it until the tick boundary. There is no mechanism by which it could.

This is not a limitation anyone is apologising for. It is how deterministic simulation works, and it is the reason a server can keep dozens of players agreeing on one shared version of events rather than each running their own private and slightly different reality. The fixed step is what makes the agreement possible.

Once you have this picture in your head, a lot of things stop being mysterious. Why a very fast projectile sometimes passes through a thin wall. Why two players can each swear they got the shot off first. Why a game feels different at range than it does at contact distance. All of it comes back to the size of the slice.

The three numbers people mash together

Here is where most of the confusion lives, and it is worth being pedantic about, because the pedantry is the useful part.

Your frame rate is how often your own machine draws a picture. It is a property of your GPU, your CPU, your settings and your monitor. It has nothing to do with the server. A server with a modest tick rate does not cap your frames, and a machine pushing enormous frame rates does not make the server simulate faster. These two numbers live on different computers.

The server tick rate is how often the world advances, as described above. It is a property of the server, chosen by whoever configured it and constrained by what the hardware can sustain under the actual player load.

The network update rate is how often the server sends you a packet describing the world, and how often your client sends packets describing your intentions. This is related to tick rate but not identical to it. A server can simulate more often than it transmits, sending you a condensed summary rather than a report from every single tick. It can also transmit at different rates to different players, or throttle updates for entities far away from you because a crate rocking gently on the other side of the map is not worth the bandwidth. Many games expose this to the player as a separate setting, and many players change it without understanding that they have changed something other than tick rate.

The reason this three-way distinction matters practically is that when a server feels wrong, the fix depends entirely on which of the three is actually broken. Choppy visuals with responsive aim is a frame rate problem on your end. Smooth visuals with rubber-banding movement is a network problem. Everything smooth and responsive until a firefight starts, at which point everyone stutters together, is a server load problem that may or may not involve tick rate at all. People troubleshooting a badly performing server frequently arrive at tick rate because it is the number they have heard of, and they change it, and nothing improves, because the actual cause was a plugin doing something expensive on every entity in the world. The performance advice for busy FiveM servers covers this pattern in more depth, and the shape of it generalises well beyond that one game.

Why more is not automatically better

If small slices are good, tiny slices must be better. That is the intuition, and it is wrong in a specific and interesting way.

Every tick costs CPU time. The server has to do the same work — physics, collision, visibility, entity logic, scripting hooks — once per tick, and that work scales with how much is in the world and how many players are in it. Double the tick rate and you have roughly doubled the per-second computational load. The server has to finish each tick before the next one is due. If it cannot, it starts running late.

A late tick is much worse than a slow tick rate. When the server falls behind schedule, the simulation stretches: time inside the game world starts running slower than time in the room you are sitting in, or the server skips ahead to catch up, and either way what you see is stuttering, warping and inputs that seem to land at random. A server running a modest tick rate that it comfortably sustains under full load will feel dramatically better than one running an aggressive tick rate it can only manage when the map is half empty. The second server is fine right up until the moment it matters, which is precisely when everyone is in the same room shooting at each other.

The cost is also not evenly distributed. Some game systems run every tick. Others run on their own slower schedules regardless of what the tick rate is set to. Raising the global rate does not necessarily improve the things you care about, because the thing you care about might be on a fixed timer that ignores it entirely. And raising the rate raises the price, because CPU that can hold a high rate under load is the expensive kind — a point that shows up quickly when you start comparing what hosting actually costs.

Then there is bandwidth. More frequent updates mean more packets, and more packets multiplied by every connected player is real outbound traffic. A server operator who raises tick rate and update rate together on a full server can discover their network pipe is the actual ceiling, not the processor.

There is a sensible ceiling for every game, and it is usually lower than enthusiasts want it to be. Past that point you are paying for something nobody can perceive.

Interpolation, lag compensation, and shooting people behind cover

Your client receives world updates at intervals, but it draws frames far more often than that. So what does it draw in between?

It interpolates. Your client holds a small buffer of recent server states and renders other players slightly in the past, smoothly sliding them between the positions the server reported rather than teleporting them from one to the next. This is why other players move fluidly on your screen even though the information about them arrives in discrete lumps. The cost is that everyone else you see is a short distance behind where the server currently believes them to be.

Now add your own network latency on top. By the time your input reaches the server, more time has passed. So when you fire at a player, you are aiming at a rendering of where they were, based on data that was already slightly old when it arrived, and your shot takes further time to get back.

Servers solve this with lag compensation. The server keeps a short history of where every player was at recent ticks. When your shot arrives, it works out what you would have been seeing at the moment you pulled the trigger, rewinds the world to approximately that state, and tests your shot against it. If you were on target from your own point of view, you hit.

This is why "I got shot behind cover" happens, and it is not a bug. From the shooter's screen you were in the open. Their shot was resolved against the rewound world where you were still exposed. From your screen you had already moved. Both of you saw a truthful rendering of different moments in time, and the server had to pick one to be authoritative. It picks the shooter's, because a game where your own aim does not register feels far worse than one where you occasionally die a fraction of a second after reaching safety.

Tick rate affects the granularity of that rewind. Coarser ticks mean the rewound world is a rougher approximation of what the shooter saw. That is a genuine argument for finer ticks in fast games. It is also an argument that gets stretched well past what it can support, because the rewind window is dominated by network latency, not by tick spacing, for the overwhelming majority of players.

Why shooters care and survival games mostly do not

In a competitive shooter, the decisive moments are short. Two players come around a corner, and the entire outcome is decided in a fraction of a second by which of them acquired the target and fired first. The temporal resolution of the simulation is directly the resolution of the contest. That is why the discussion is loudest around Counter-Strike and its descendants, where a small timing difference is the difference between a duel won and lost, and where players are practised enough to notice.

Valve's own changes to how community servers handle networking are a good illustration of how much of this sits below the tick rate headline — the details of that shift are worth reading in the CS2 community server networking update, because it reframes several things people had assumed were settled.

Now consider a survival or building game. You are gathering materials, placing structures, managing a base, occasionally fighting. The interactions that matter play out over seconds or minutes, not milliseconds. Whether the world advanced a few extra times per second while you were placing a foundation is irrelevant to your experience. What you actually care about is whether the server can hold thousands of persistent entities without falling over, whether saves are reliable, and whether it stays up. A Rust or 7 Days to Die server operator who spends their optimisation budget on tick rate instead of on entity counts and save performance has misread which knob does anything. Minecraft sits in the same category, where the practical constraints are chunk loading, entity density and what the server software does with them — which is why the choice of server implementation tends to matter far more than any tick setting.

Cooperative and sandbox games land in between. A Garry's Mod server running a physics-heavy gamemode has genuine simulation demands, but the tolerance for imprecision is enormous compared to a competitive match. Left 4 Dead 2 is a shooter where the opponents are mostly not other humans, which removes the duel problem entirely. The right rate is the one the game's own pacing asks for.

Comparing numbers across games means nothing

This one deserves saying plainly: a tick rate figure from one game cannot be meaningfully compared to a tick rate figure from another.

Different engines do different amounts of work per tick. One engine might run full physics, all entity logic and all scripted behaviour on every tick. Another might run movement on a fast loop and everything else on slower staggered loops, so its headline number describes only a fraction of the simulation. A third might decouple transmission from simulation so completely that the tick figure tells you almost nothing about what reaches your client.

They also measure differently. Some report the target rate the server aims for. Some report a running average of what it actually achieved, which is far more informative and far less flattering. Some report the physics step, which may not be the same as the game logic step.

So when someone says one game's servers run at a "better" rate than another's, they are comparing two quantities that share a name and nothing else. The number is only comparable within a single game, between servers running the same build with the same configuration, and even then it needs to be a measured figure under load rather than the value someone typed into a config file. This is one of several reasons a headline stat in a listing should be read as a claim rather than a fact, which is part of a broader question about what makes a server listing trustworthy.

What you can actually feel

Honestly? Less than you think, and not the thing you think you are feeling.

What players perceive is a composite. Your latency to the server. The consistency of that latency, which matters far more than its size — a steady connection at moderate ping feels better than an erratic one that is sometimes brilliant and sometimes awful. Your own frame timing. The client's interpolation settings. Whether the server is holding its schedule or quietly falling behind during busy moments. Packet loss, which produces symptoms that look exactly like a low tick rate to anyone who has not measured.

Tick rate contributes to that composite, but it is one term among many, and rarely the dominant one. A player who joins a server and declares the tick rate too low is usually reporting a real sensation with a guessed cause. The sensation is worth taking seriously. The diagnosis is not, unless it comes with measurements.

What you genuinely can feel: a server that degrades under load, because the change is obvious when the population crosses some threshold and everything gets worse at once. Registration that behaves differently at different ranges. Movement that corrects itself visibly after you have already committed to it.

What you cannot feel: the difference between two servers a few ticks apart, both of which are holding their schedule, on a connection where your latency dominates. If you want to know, you measure — most competitive games expose net graphs and console commands that report the server's actual performance rather than its intended performance. That measured number, taken while the server is full, is the only tick rate figure worth anything. Sorting through servers on the main list and testing a few during peak hours will tell you more in twenty minutes than a week of reading claimed specifications, and a systematic approach to finding good servers makes that search shorter.

Frequently asked questions

Does a higher tick rate reduce my ping? No. Ping is the round-trip time between your machine and the server, and it is determined by physical distance and the route your packets take. Tick rate affects how often the server acts on what it receives, not how long your packets spend travelling. A server on another continent will have high latency at any tick rate.

Will more frames per second make the server tick faster? No. Your frame rate is generated on your machine and the tick rate is generated on the server. They are separate loops on separate computers. High frames make your own view smoother and can slightly reduce the delay between your input and it being sent, but they do not touch the simulation.

Why do I sometimes get killed after reaching cover? Lag compensation. The server rewinds to approximately what the shooter was seeing when they fired, and at that moment you were still visible to them. The server resolved the shot fairly from their point of view. It looks unfair from yours because you are seeing a later moment in time.

Should I pick servers based on advertised tick rate? It is a weak signal. An advertised figure is a configuration value, not a measurement, and it tells you nothing about whether the server holds that rate when full. Population at the hours you play, stability and whether the place is actually run by someone attentive matter far more — and if your own server sits empty, tick rate is almost certainly not the reason, as the usual causes tend to be more mundane.

Does raising tick rate on my own server help? Only if the server has CPU headroom to sustain it at full population, and only if the game is one where the extra resolution is perceptible. For most community servers the better spend is on making sure the existing rate is held consistently under load. Test with a full server, not an empty one.

How does slot count interact with tick rate? Directly. Every additional player adds work to every tick and outbound traffic to every update. A configuration that runs comfortably at low population can miss its deadline at capacity, which is why choosing a slot count should be done with the tick rate you intend to run, on the hardware you actually have.

Is tick rate different on modded servers? The nominal rate is whatever you set, but mods and scripts run inside the tick, so heavy modifications increase the work each tick must complete. A server with substantial scripting can miss its schedule at a rate that ran fine unmodded. The setting stays the same; the achieved rate drops.

JoinGG is a live directory of community game servers — current status, players online right now, and a copyable address for every listing.