Session timelines catch network bugs that are unreliable to reproduce, difficult to observe, and hard to diagnose. Changing network conditions make reproduction inconsistent. Important events can vanish without clear traces. Player symptoms such as rubberbanding, desync, and invisible projectiles often occur well after the real cause.
Building Tashi and instrumenting the first titles we supported gave us this debugging toolkit. Here is the order in which we usually use it.
Begin With a Session Timeline
Before using packet-level tools, capture a full timeline from a failing session. Use timestamped client and server logs tied to one clock reference. Record received player inputs, sent and received state updates, and server-issued corrections.
Timelines usually expose a recognizable signature. Rubberbanding appears as clustered server corrections after client-predicted and server-authoritative state split. An invisible projectile appears as a server hit with no client confirmation. Desync begins at the timestamp where client and server logs diverge, leaving inconsistent records.
The timeline gives you location and timing. The remaining work is finding the cause. Skip it for hypotheses and you can spend hours investigating the wrong component.
Replay Packets to Reproduce Flaky Bugs
The toughest network bug happens once, in one session, under conditions you cannot recreate reliably. Packet replay records the entire session and plays it back deterministically. The server gets identical packets, in identical order and timing, so you can inspect the result.
This is our key tool for intermittent bugs. It turns a flaky failure into a repeatable one. Then you can add instrumentation, alter one variable at a time, and narrow down the cause.
A basic replay tool captures packets at the session boundary, timestamps them from session start, and sends them through the session handler using that relative timing. Server-state non-determinism is the main complication: stochastic behavior makes the replay diverge. Replay is far more useful with a fully deterministic server state machine.
Inject Latency and Jitter
Some network bugs surface only within particular latency ranges. A failure at 80ms may stay hidden at 5ms, so LAN-only testing misses it. Condition injection tools, built into development environments or placed in a proxy layer, add delay, jitter, and packet loss to selected connections while leaving the rest of the test environment unchanged.
Test at least three conditions: near-zero latency as a baseline, 60ms to 80ms for same-region players, and 120ms to 150ms for cross-region players. Add 1% to 3% packet loss in the second and third cases. These three conditions expose many latency-sensitive game-code bugs.
Tashi's session dashboard displays measured RTT for every player during a live session. For post-incident work, this helps: a player reporting trouble with 180ms throughout likely has a different problem from one reporting the same trouble at 20ms.
Log State Diffs
A state diff captures a client-server disagreement: what the client thinks is true versus what the server knows is true. Logging each diff, its size, and its frequency directly measures client-side prediction quality.
Healthy sessions show small diffs infrequently. Client prediction stays near the server-authoritative state, so corrections remain minor. Large or frequent diffs signal prediction failure, with the client pulling away faster than corrections bring it back.
Large diffs commonly come from input prediction that ignores server validation, such as predicting an action the server rejects; floating-point non-determinism causing client and server physics to diverge; or lag spikes that interrupt corrections and let prediction error build up.
Production Metrics by Player
Some network bugs exist only in production, with real players and real connections. Controlled tests cannot reproduce issues tied to particular network paths, ISP behavior, or connection combinations absent from development.
Production telemetry is the tool here: per-player, per-session metrics identify affected sessions and show what differed. At minimum, collect each player's RTT, packet loss rate, jitter, and correction event rate. Together, these usually separate "this player had a bad network" from "this session had a bug that appeared specifically for this player."
We added this telemetry to Tashi because development required it. Every instrumented session collects these metrics and presents them in the analytics dashboard. It does not replace the local tools above, but it finds bugs produced only by the real world.
One Rule for Every Tool
Network debugging is iterative. The first tool rarely reveals the cause. Form a hypothesis from observable symptoms, select the tool that can confirm or reject it, observe, then revise the hypothesis. Packet captures before a session timeline usually waste hours. After the timeline identifies a specific event sequence, those captures are the right next step.
The tools are ordered from higher-level to lower-level deliberately. Begin where each minute gives you the most information. Go deeper only after the high-level view shows where to investigate.
Tashi's session dashboard shows real-time per-player RTT, packet loss, and correction event telemetry. Start free for 50 concurrent players.