How Tick Rate Affects Hit Registration Explained (2026)

Tick rate controls how often a game server refreshes its copy of the world, and that refresh rate decides how stale the server’s version of every player can be when your shot arrives. Higher tick rates shrink that staleness window, so more of the shots you feel were on target actually register as hits. They cannot repair a bad route, a lossy Wi-Fi connection or a delayed hit-confirm effect, which is why low ping with bad hit registration is such a common experience.

This is the short version. The rest of the article unpacks it: what a tick actually is, how the server decides a shot landed, what changes between 32, 64, 128 and sub-tick servers, and how you can check the numbers on your own machine before you blame the game.

What Is Tick Rate in Multiplayer Games?

Tick rate is the number of times per second a multiplayer server advances and broadcasts its simulation of the game world, expressed in hertz (Hz). A 64-tick server runs 64 of those updates every second. It measures player positions, weapon states, grenade arcs and ability effects, then sends the result out to everyone connected.

That number divides evenly into a second. A 64 Hz server has roughly 15.6 milliseconds between updates, a 128 Hz server about 7.8 milliseconds, and a 20 Hz server a full 50 milliseconds. Those milliseconds are the gap where the server is working from information it has already decided is slightly out of date.

Tick rate is not the same thing as ping, and players constantly blur the two. Ping measures how long a packet takes to travel between your machine and the server and back. Frame rate measures how often your own monitor draws a new image. All three matter, and they live on completely different clocks.

• Tick rate is a property of the server and its host. You cannot change it from your PC.
• Ping is a property of the route your packets take. It moves up and down during a match.
• Frame rate is a property of your hardware, your settings and the game itself.

Here is a concrete example. You are holding an angle on a doorway. An enemy crosses it during the gap between two server updates. At 64 Hz, the server’s stored position for that enemy can be up to 15.6 milliseconds behind where the player was really standing. At 128 Hz, that worst case halves to 7.8 milliseconds. In both cases the server takes your shot’s timestamp and checks it against the closest state it has.

That gap is small in isolation. It only becomes a visible problem when a fast strafe, a quick peek or a high-ping round trip pushes a genuinely on-target shot into that window of stale positions.

What Hit Registration Means and Who Decides a Shot

Hit registration is the process of deciding whether a shot you fired actually connected with a target. In almost every modern multiplayer shooter the server holds the final say, because a client that judged its own hits would make cheating trivial. Your game is server authoritative: what you see is a prediction, and what you are told happened is the result.

Riot’s engineering write-up on the subject of hit registration in Valorant draws a useful line between correctness and clarity. Correctness means the server’s verdict matched the real world. Clarity means the feedback you received made that verdict understandable. A game can be entirely correct and still feel broken, which is why some legitimately registered hits look wrong to the player who landed them.

From mouse click to hit marker, step by step

The pipeline runs roughly like this in a server-authoritative shooter. Every stage adds a little time, and the tick rate sits at the point where the server samples the world.

1. Input capture. The game registers your click with a precise timestamp, usually finer than the tick interval itself.
2. Client prediction. Your game immediately plays the shot locally so the muzzle flash and recoil feel instant, rather than waiting a full round trip.
3. Send to server. The shot, its aim vector and its timestamp travel over your connection.
4. Server rewind. The server pulls stored world states back toward the shot’s timestamp. This lag compensation is what lets you hit someone who has already moved on in your view.
5. Validation. The server checks the ray against hitboxes at those rewound positions and decides hit or miss.
6. Result returns. A hit, damage, armor and headshot status come back over the network.
7. Feedback plays. Your hit marker and hit-confirm effects appear, possibly after a delay that depends on your connection.

Stages four and five are where tick rate matters most. The server can only rewind to states it actually stored, and it can only sample positions at the resolution it simulates.

How Tick Rate Affects Hit Registration

Higher tick rate affects hit registration by shrinking the window in which the server’s stored positions can be out of date relative to your shot. When a shot is judged against a fresher copy of the world, the gap between what you saw on screen and what the server believed is smaller, so the rate of visibly on-target shots that fail drops.

The mechanics are easier to see with an input delay example. Suppose a player is strafing across your crosshair at a steady speed. Between the last server snapshot and the moment your shot is evaluated, the player travels some distance that the server has not accounted for. The faster the movement and the longer the interval, the further that distance grows. At 20 Hz, 50 milliseconds of unaccounted movement is a large gap. At 128 Hz, the same mistake can be only 7.8 milliseconds.

A second effect is input granularity. On a fixed-tick model, inputs that arrive between two server updates are usually processed together in the next update. Two opposing actions that land in the same tick get resolved by the server’s ordering rules rather than by true simultaneity, and the player who happened to be processed second can be the one who loses the exchange. More ticks means smaller windows for that kind of ambiguity.

A third effect is physics. Grenade arcs, bullet drop for projectiles, and knockback are all resolved as the server simulates them. At a coarse tick, those curves are stepped rather than smooth, and a projectile can appear to jump. It is one more source of the feeling that the game is not showing you the truth.

The role of latency, ping and interpolation alongside tick rate

Tick rate is only one term in the equation. Latency is the other big one, and the two multiply out in ways players rarely work through.

Consider a 64-tick server. Your shot is queued against a position that may already be up to 15.6 milliseconds old. Now add 100 milliseconds of round-trip time, split across prediction and confirmation, and your shot is effectively being judged against a world snapshot that is far older than the tick interval alone would suggest. Doubling the tick rate to 128 trims 7.8 milliseconds from a budget that already contains hundreds. It helps; it does not solve the problem.

Interpolation makes this stranger. To hide network delay, clients render other players slightly in the past, smoothly sliding between received states. The result looks fluid, and it means the enemy you are aiming at is not standing exactly where the server currently has them. That gap is deliberate and unavoidable in any system trying to hide latency.

Peeker’s advantage follows from the same physics. Whoever sees the opponent first usually gets the first shot registered, because the other player’s action has not yet reached the server. Tick rate narrows how wide that advantage feels by tightening timing, but it cannot reverse the direction of a network round trip.

Correctness versus clarity, and why a hit can be real but look wrong

Not every complaint about hit registration is a bug. A body shot that registers correctly can look like a headshot if the hit-confirm effect arrives late and your own enemy model has moved by the time you see it. A kill can appear to happen a step to the left of where the shot landed. Players reading the Riot post on hit registration describe exactly this class of problem, and the fix belongs to the game’s visual feedback rather than to its simulation.

The practical version of that distinction: if your shots consistently do damage but the effect looks wrong, you are probably looking at a clarity issue. If your shots consistently do nothing while the crosshair sits on the model, you are probably looking at a correctness issue, which points at tick rate, latency or your connection.

The Relationship Between Tick Rate, Ping and Latency

Tick rate and ping are independent. A 128 Hz server can sit 200 milliseconds away from you, and a 64 Hz server can sit 8 milliseconds away. Neither number predicts the other, and improving one does not move the other.

What tick rate controls is only the freshness of the server’s own simulation. What ping controls is how long your commands take to reach that simulation and how long the answer takes to come back. A high tick rate cannot shorten a route that physically travels a long way, and it cannot repair packet loss on the last hop of your connection.

The practical ranking is straightforward. If your ping is high and your packet loss is zero, tick rate is your only remaining variable and a better server can help. If your ping is low but your connection drops packets or spikes, tick rate changes very little, because missing or delayed commands corrupt the picture regardless of how often the server updates.

Tick Rate Examples: What Changes at 32, 64, 128 and Higher

The table below is the whole concept in one grid. The tick interval is how long the server can go on running its simulation before refreshing it.

Tick rate	Tick interval	What it means in practice
10 Hz	100 ms	Visibly choppy movement and projectile arcs; rare in competitive shooters
20 Hz	50 ms	The classic default for simulation-heavy sandbox and survival games
24 Hz	about 41.7 ms	The rate players in Call of Duty and Warzone discussions reported during the low-tick era
30 Hz	about 33.3 ms	Older console shooters and plenty of mobile titles
32 Hz	31.25 ms	Still common in survival servers and console battle royale
60 Hz	about 16.7 ms	Standard for the largest battle royale servers, where player counts drive the budget
64 Hz	15.6 ms	The long-standing competitive baseline for tactical shooters
128 Hz	7.8 ms	The enthusiast ceiling for fixed-tick servers; roughly halves the staleness window
144 Hz	about 6.9 ms	Diminishing returns for most players over 128 Hz

Read the middle column and the pattern becomes obvious. Doubling the tick rate always halves the interval, but the improvement you feel shrinks faster than the number does. The step from 20 to 64 Hz is transformative. The step from 64 to 128 Hz is noticeable to sensitive players. The step from 128 to 256 Hz is where players on r/GlobalOffensive broadly agree the difference stops being noticeable.

That is not a physical limit. It is a threshold where the remaining error becomes smaller than the other noise in the system: your aim, your reaction time, your frame rate and your connection.

Why Hit Registration Can Still Feel Wrong

If you have fixed your ping and your packet loss and shots still fail, the cause is usually one of these.

Packet loss and jitter

Lost or badly delayed packets scramble the ordered stream of updates. Your client predicts, guesses wrong, and the server corrects it. Players on r/CODWarzone linked low server rates with fast movement, skill-based matchmaking, ISP routing and burst packet loss as a bundle of compounding causes, rather than a single clean explanation.

Server load

A server advertised at 64 Hz drops below that when the machine cannot keep up. Players on r/GlobalOffensive have argued for years that CS2 server performance, not tick rate, is behind most perceived desync, since the newer engine is heavier to simulate.

Client prediction errors

Your game shows you an outcome the server has not confirmed yet. When the server disagrees, the view snaps. Fast strafing, jumping and rapid weapon switching are where prediction errors are most visible.

Rollback and interpolation mismatch

Some shooters reconcile client and server states after the fact. The reconciliation itself can look like a teleport or a shot that lands a fraction of a second late. Players see the correction, not the internals.

Input delay and frame rate

A game running below your monitor’s refresh rate adds delay between your click and the frame that shows it. That is not a netcode problem, but it feels exactly like one, and it is easy to mistake for bad hit registration.

Hit-confirm VFX arriving late

Damage numbers, blood effects and hit markers are subject to the same round trip as everything else. Late feedback makes a correct hit look incorrect.

Hitboxes and peeker’s advantage

Some characters have forgiving or punishing hitbox geometry, and being the one to see the opponent first still resolves duels in your favour. No tick rate setting rewrites that.

Why Game Servers Do Not Just Run 256 Tick

Because every tick is CPU work multiplied by every player on the server, and the bill grows fast.

A server simulating at 128 Hz does roughly twice the physics and state work of a 64 Hz server for identical player counts. Hosting providers price that directly, which is why the biggest battle royale titles settle around 60 Hz and survival servers often offer a 32 Hz option. Bandwidth scales too, since more frequent snapshots mean more data sent to every connected client.

There is also a diminishing returns argument. Past 128 Hz the interval is already below what most players can perceive through aim and reaction time, so extra cost buys very little. The sensible engineering answer is usually sub-tick timestamping instead of a bigger number, which is what CS2 moved toward.

Tick Rate in Popular Multiplayer Games

Here is a cross-game reference. Rates change between seasons, so treat this as a starting point and verify the current value with the methods in the next section.

Game	Tick model	Notes
Counter-Strike 2	Sub-tick	Replaced fixed tick intervals with per-action timestamping, aimed at exactly the shot-timing problems discussed here
Counter-Strike: Global Offensive	64 tick standard, 128 tick on third-party matchmaking	The split that created the two-tier competitive complaint
Valorant	64 tick	Deliberately fixed, with hit-confirm work done on feedback clarity rather than raw tick rate
Call of Duty / Warzone	Around 24 Hz during the low-tick era	The rate players reported during the period of heavy complaint; current values vary by title and platform
Apex Legends	60 tick	A compromise driven by very large match sizes
Fortnite	Varies by mode	Rebuild and lobby configurations differ, so check in-game rather than assuming
Rust	Server-configurable	Hosters advertise rates directly, commonly in the 30 to 60 range for populated servers
Minecraft Java	Default 20, configurable, 10000 and beyond on high-end servers	The tick rate here is simulation speed, so raising it also raises the plugin and hardware load

The pattern across that list is worth stating plainly. Competitive tactical shooters sit at 64 or move to sub-tick. Large-scale survival and battle royale games sit lower because player counts, not ambition, set the ceiling.

Does a Higher Tick Rate Always Improve Aim?

No. A higher tick rate improves the timing of shot evaluation, not your ability to place a shot.

What it genuinely improves is the accuracy of the server’s view of fast movement at the moment your bullet is judged. What it does not touch is your crosshair placement, your sensitivity, your recoil control, your reaction time, or whether you can see your enemy clearly against a busy background.

Two players on the same 128 Hz server can produce wildly different results, because one of them is compensating for a bad read of the opponent. A player on a 32 Hz server with excellent positioning and a straight crosshair placement will often beat a player on 128 Hz who panics on the flick. Frame rate matters here too, since a game running below your monitor’s refresh rate adds delay to every input regardless of server rate.

If you are choosing between improving your setup and switching servers, fix the frame rate and the connection first. Those have clearer, cheaper effects on your actual results.

How to Check the Tick Rate and Diagnose Your Setup

Work through this in order, because each step tells you whether the next one is worth doing.

Find the server’s real tick rate

In Counter-Strike 2 and CS:GO, the developer console and the match scoreboard display server information including tick rate and player count. In Minecraft, server operators publish the rate in their server list and can be asked directly. In Rust, the host’s server browser and description list the tick rate. For console shooters, the in-game network graph available on PlayStation and Xbox shows tick and bandwidth figures, and the PC equivalent is the console command that overlays the same data. Where a game offers no readout, community server browsers and in-game scoreboards usually publish it.

Check your ping and, more importantly, your stability

An average of 40 milliseconds that never moves is better for hit registration than an average of 25 that spikes to 180 every time someone starts a microwave. Watch the graph, not just the number. A steady line beats a low average with frequent spikes.

Test for packet loss

Run a continuous packet loss test from the PC while you play. A wired connection on Ethernet with zero loss is the baseline worth aiming for before you blame the server. Wi-Fi on a congested band is the most common cause of the specific complaint that shots which clearly hit do nothing.

Check your frame rate

If a competitive game runs below your monitor’s refresh rate, your inputs are being sampled more slowly than your display refreshes. That is input delay, and no server change touches it.

Test the same game on a different server

If your connection is clean and your frame rate is solid, move to a server in another region or on a different host and see whether the behaviour follows you or stays behind. Shots that fail on every server point at your setup. Shots that fail on one server only point at that server.

That distinction is the most useful diagnostic most players never run, and it takes one match to complete.

How Tick Rate Affects Hit Registration in Practice

Tick rate raises hit registration by keeping the server’s stored world closer to what you actually saw. When a higher tick rate matters most, it is in fast strafing, close peeks, low-ping play and any game where hitboxes move quickly between updates. When it does not matter, it is when your problem is a lossy connection, a route with 150 milliseconds of latency, a frame rate below your refresh rate, or a game with a fixed 64 Hz server that will never move.

Before changing anything, collect evidence: your actual server tick rate, your ping graph over a full match, your packet loss percentage and your frame rate. Those four numbers explain most hit registration complaints on their own, and they tell you which lever is worth pulling.

Frequently Asked Questions

Conclusion

Tick rate affects hit registration by keeping the server’s stored view of the world fresher at the moment your shot is judged. Higher rates make on-target shots register more reliably, and they stop there, because ping, packet loss, frame rate and late visual feedback cause most of the complaints players actually mean.

Check four things before changing anything: your real server tick rate, your ping stability over a full match, your packet loss percentage, and your frame rate against your monitor’s refresh rate. Then act on whichever one is wrong. Chasing the biggest tick rate number rarely fixes a connection problem, and it is the most expensive way to feel better without being better.