Bug Reporting for Games With Server Tick Rates

The server tick rate is one of the most consequential numbers in a multiplayer game, and one of the least visible to players. It sets how many times per second the authoritative simulation advances, which bounds how quickly the server can react to input, how precisely it can resolve collisions, and how fresh the state it sends to clients is. A great many bugs that players describe as lag are not network problems at all; they are the simulation stepping too slowly or unevenly. This post covers the tick rate, step timing, and overrun data you need to capture so you can tell a tick-rate problem from a network problem, because the fixes could not be more different.

What the tick rate actually bounds

The tick rate is the heartbeat of the server simulation. At thirty ticks per second the server only looks at the world about every thirty-three milliseconds, so an input that arrives just after a tick waits most of that interval before it is processed, and a fast-moving object can travel a noticeable distance between collision checks. Doubling the tick rate halves that worst-case input latency and tightens collision precision, which is why competitive games push tick rates high. The number is a direct lever on how responsive and fair the game can possibly feel.

It is also a cost lever, because every tick consumes CPU on the server, and higher tick rates mean fewer matches per machine. This tension is why tick rate is a deliberate design choice rather than a maximize-it default, and why some bugs are really the symptom of a tick rate chosen too low for the gameplay. A precise platformer or a twitch shooter on a thirty-tick server will generate complaints that more bandwidth or better netcode cannot fix, because the root cause is how often the simulation looks at the world. Capturing the configured rate is the first step to recognizing this class of bug.

Tick budget overruns and the catch-up spiral

Each tick has a time budget, the interval between ticks, and the server must finish all its simulation work within it. When a tick runs long, because a crowd of entities spawned, a physics query got expensive, or garbage collection fired, it overruns the budget and the next tick starts late. A well-behaved server absorbs an occasional overrun, but a sustained one forces the server to either drop ticks or run several in quick succession to catch up, and both produce visible timing artifacts that feel exactly like network lag to players.

The catch-up spiral is the dangerous failure: ticks consistently run over budget, the server falls further behind, and its attempts to catch up consume even more time, degrading the whole match. Capturing the measured step time per tick alongside the budget reveals this immediately, where a player can only report that the game got laggy at a certain point. A report showing step times creeping toward and past the budget points squarely at server performance, not the network, and it often correlates with a specific in-game trigger like a large fight or a particular ability.

Telling tick-rate bugs from network bugs

The symptoms overlap brutally: delayed input response, jerky movement, and hits that do not register can all come from either a slow tick or a bad network. The way to separate them is to capture both sets of metrics together. If the round-trip time is fine but the server step times are spiking, the problem is the simulation, not the connection. If the step times are healthy but latency is high, it is the network. Capturing one without the other guarantees you will sometimes chase the wrong layer, wasting days optimizing a network path that was never the bottleneck.

This distinction is especially important because the two have opposite fixes. A network problem might call for better routing, region selection, or more aggressive prediction; a tick-rate problem calls for optimizing the simulation, raising the tick rate, or shedding load. Capturing the server tick number alongside client-side timing also lets you check whether the client and server agree on time at all, since a tick-rate instability often shows up first as the two clocks drifting. Every timing bug report should carry both the network and the tick metrics so the layer is never in doubt.

Variable timestep and determinism risks

Some servers run a fixed timestep, advancing the simulation by a constant interval each tick, while others use a variable timestep that scales with real elapsed time. Fixed timesteps are more predictable and are essential for deterministic systems, but they can fall behind under load; variable timesteps keep up with wall-clock time but introduce timing variability that can change physics outcomes and break determinism. Bugs that only appear under server load are frequently the timestep stretching or the simulation skipping, and the report needs the actual delta-time values per tick to show it.

Capturing the delta time the simulation actually used, not just the configured rate, is what exposes these. A physics interaction that behaves differently when the server is busy is a timestep bug, and it is invisible if you only log the intended tick rate. For any system that relies on determinism, like a server that must reconcile with client prediction, an unstable timestep is corrosive: it makes the authoritative simulation itself unreliable. The measured delta times turn a load-dependent physics glitch from an unreproducible curiosity into a clear timestep problem with a known trigger.

Setting it up with Bugnet

Bugnet's in-game report button captures state when a player flags a problem, and you can extend the captured payload with server-side timing pulled from the match the player is in: the configured tick rate, recent measured step times, the budget, any overruns or dropped ticks, and the timestep delta values. Add player attributes for the server region and the match's player count, since overruns often correlate with crowding. When a player reports lag, the report can immediately show whether the server was keeping up, distinguishing a tick-rate problem from a network one before anyone opens a profiler.

Tick-rate problems recur under the same triggers, so Bugnet's occurrence grouping folds duplicate reports into one issue with a count, revealing that lag spikes cluster around a specific event, like a boss spawn, rather than as random complaints. Use custom fields for peak step time, player count, and whether the budget overran, then filter to find whether timing problems concentrate at high population. One dashboard correlates player-perceived lag with actual server step times, which is the correlation that lets you confidently say a complaint is performance, not packets, and optimize the right thing.

Profiling and capacity planning

The teams that keep tick rates stable treat server step time as a metric they watch continuously, not something they check after complaints. Log step times in production and alert when they approach the budget, so you catch a creeping overrun before it spirals. Load-test with realistic worst-case scenarios, the maximum player count doing the most expensive actions at once, and capture the step times, because the tick budget is fine at low load and only breaks at the population and intensity a real peak brings.

Capacity planning follows directly from this: knowing how step time scales with player count tells you how many matches a machine can host without overrunning, which is both a cost and a quality decision. Treat a step-time regression in a new build as seriously as a crash, because a server that cannot hold its tick rate makes every other netcode system unreliable. With step times captured on relevant reports and watched in production, you can choose your tick rate deliberately and defend it, rather than discovering at peak concurrency that the simulation cannot keep its own heartbeat.

Not all lag is network lag. Capture server step times against the tick budget and many laggy reports turn out to be the simulation missing its heartbeat.