1. Docs
  2. Diagnosing a Player Lag Complaint

Diagnosing a Player Lag Complaint

A step-by-step playbook for the situation every admin knows: a player says the server is lagging, you don't see it, and the conversation is going nowhere.

Background reading: How DayZ multiplayer actually works — the short version is that "lag" has four possible homes (server simulation, server host machine, the player's network, the player's machine), and the whole job here is figuring out which one you're in.

Ground rule: adjudicate data, not credibility. A desyncing player genuinely experiences what they describe — their client's view of the world really was wrong. Treating the complaint as whining burns a player relationship and loses the diagnostic signal. Treating it as proof the server is broken wastes your weekend. Run the procedure instead.

Step 1 — Scope: one player or many?

Before anything else, count. Not messages — distinct players.

  • Scan recent in-game chat and tickets for lag/desync mentions over the complaint window.
  • Ask in global chat during the reported window: "anyone else getting lag right now?"
  • Check the other servers too — a fleet-wide pattern means something shared (host, mod update); a one-server pattern means that server; a one-player pattern means that player.

Watch for the counting traps:

  • Tickets undercount. Players complain in game chat and Discord long before they file tickets — and desyncing players often file cheater reports instead of lag complaints, because that's what desync looks like from inside.
  • Wipe days overcount. Queues, mass relogs, and crash recoveries generate complaint noise that has nothing to do with a real regression.

If several players report it in the same windows → server-side. Skip to Step 5. If it's genuinely one player while teammates standing next to them are fine → Steps 2–4.

Step 2 — Timing: does it match the server-lag pattern?

Server-side lag has a signature: high population, late in a restart cycle, everyone affected, gone after restart. Check the complaint timestamps against the restart schedule and population:

  • Complaints at 3am at 20 pop, 40 minutes after a restart → almost certainly not server simulation load.
  • Complaints clustering in the last hour before restarts at 60+ pop → classic server-side; go to Step 5.

Step 3 — The interview

Five questions, all quick:

  1. When exactly did it last happen? (date, time, timezone — you need this to check anything)
  2. What does it feel like? Warping/teleporting/late hits with smooth framerate → network. Whole-game freezes/stutters/low FPS → their machine.
  3. Wired or WiFi?
  4. Does it happen on other servers / other games too?
  5. What's your in-game FPS during a bad moment? (they can screenshot the counter)

Step 4 — The homework (copy-paste message)

This is the step that ends arguments, because it produces evidence either way. Send this:

Happy to dig into this, but we need data from your side of the connection — the server can't see your network path. Two tests, ~10 minutes total:

1. WinMTR (network path test) — run this WHILE playing: - Download WinMTR (free), enter the server address: <SERVER_IP>, click Start. - Play normally for 10–15 minutes, especially until the lag happens. - Click Stop, then "Copy text to clipboard", and paste the result here. - What it shows: packet loss and delay at every hop between you and us.

2. If you're on WiFi: plug in a cable and play one session wired. WiFi is the #1 cause of the exact symptoms you're describing, even with "full bars".

If the game freezes/stutters rather than warps: also send a screenshot of Task Manager → Performance tab (CPU, Memory, and your disk) taken during play, plus your in-game FPS during a bad moment.

Optional extras for stubborn cases: a bufferbloat test (waveform.com/tools/bufferbloat) run while someone else in the household streams/uploads; checking whether "lag" hours coincide with household streaming/backup hours.

Step 5 — Reading the results

WinMTR:

  • Loss at hop 1–2 (their router / modem): their home network. WiFi, cabling, or router.
  • Loss starting mid-path AND continuing on every hop after it, including the last: a real path problem (their ISP or a peering point). Nothing you or they can quickly fix — they can report to their ISP; a VPN sometimes routes around it.
  • Loss at one middle hop but 0% at the final hop: not a problem. Routers deprioritize replying to probes while forwarding traffic fine. This is the most misread line in every WinMTR paste — only loss that persists to the final hop counts.
  • Clean WinMTR but symptoms continue: either the bad moment didn't occur during the test (have them run it longer), or it's their machine → Task Manager screenshot: memory near 100% or a disk pinned at 100% during freezes = paging/disk problem on their PC.

Server-side check (owner/staff dashboards): the server Diagnostics page shows lag-risk over each session — whether the server was actually struggling during the reported window, and whether it typically degrades late in a cycle. A clean server reading during the player's worst episode, combined with unaffected teammates, closes the case as player-side.

Step 6 — Delivering the verdict

Player-side (network):

Ran the checks: during your worst episodes the server was healthy and other players in your area weren't affected — and your path test shows packet loss at <hop>. That's why you're seeing warping and late hits with a good ping: ping measures delay of packets that arrive, and your issue is packets not arriving. Things that actually help: wired instead of WiFi, checking your router, reporting the loss to your ISP. Happy to re-check after you change something.

Player-side (machine):

Your symptoms (freezes then catch-up, FPS drops) plus the Task Manager screenshot point at your PC rather than the connection — memory/disk are maxing out during play. Server-side we show healthy performance in those windows.

Server-side confirmed:

You're right, and thanks for the timestamps — the server shows degraded performance in exactly those windows. It's the known late-cycle pattern at high population / it's been escalated. In the meantime it's worst in the last hour before a restart.

Never deliver "it's your connection" without having actually checked the server side for the reported windows — being wrong once costs all future credibility.

Traps (each one has burned someone)

  • "My ping is 30, so it's the server." Ping ≠ loss/jitter. See the background guide.
  • "Nobody else is complaining." Check game chat before saying this — ticket counts miss most complaints, and you may find a quiet chorus.
  • One loud player ≠ the only affected player. One loud player ≠ a server problem either. Count distinct players; let the count decide.
  • Post-hoc blame: "it started when you added X" — verify the timeline; complaints regularly predate the change they're blamed on, and wipe/crash confounds regularly coincide with it.
  • Crash nights pollute everything. If the server crashed during the window, set those complaints aside; they're about the crash.

Escalating to the Server Manager

The Server Manager is whoever is responsible for the server setup itself — performance, configuration, mods, hosting. If the procedure points server-side (or won't resolve), escalate to them with:

  • Server name, exact timestamps + timezone of at least 2–3 episodes
  • How many distinct players were affected (and names/ids of a few)
  • The complaining player's id, their WinMTR paste if collected
  • Whether the windows were near restart boundaries or a crash

With timestamps the Server Manager can check server frame health, per-player session/reconnect patterns, and complaint trends for the exact windows — usually a same-day verdict.