Reading DayZ Admin Logs: A Field Guide

(the .ADM file, line by line)

Every "who killed who", "who raided our base", and "was that guy really where he said he was" question ultimately lands in one place: the server's admin log — the .ADM file. It's plain text, it's readable in Notepad, and most admins never learn to read it properly. This guide fixes that.

Turning logging on

The admin log doesn't exist until you ask for it. Two switches, both server-side:

1. The -adminlog launch parameter. Add it to the server's startup line. Without it, no .ADM file is written at all. Most hosting panels have a checkbox for this (often on by default — check yours before assuming you have history).
2. Flags in serverDZ.cfg that add extra event types on top of the baseline:

The baseline (just -adminlog, all flags 0) already gives you connects, disconnects, chat, hits, kills, unconsciousness, and deaths. The flags are cheap; unless you have a specific reason, turn on placement, build actions, and the player list — the 5-minute position snapshots are the single most useful thing for reconstructing events after the fact, and you can't add them retroactively.

Where the files live (and how they vanish)

The .ADM files are written to the server's profiles folder — the directory you pass with -profiles= on the launch line. On rented servers you reach it through your host's file manager or FTP; every panel names it slightly differently (profiles, config, ServerProfile), but it's the folder that also holds your crash logs and .RPT files.

The files look like DayZServer_x64_2026-08-07_18-01-33.ADM — one file per server session. The server creates it at startup and appends to it until shutdown, so the newest file is the live one. The timestamp in the name is when that logging session started, and it is the only place the date appears — the lines inside carry time-of-day only. (The prefix matches the server executable — DayZServer_x64 on Windows, DayZServer on Linux. Older game versions wrote a single un-timestamped DayZServer_x64.ADM, and some hosting docs still describe that; modern servers timestamp every session natively, no mods or manager tools required.)

Files roll on every server restart — that's the game's own behavior — so a server on a 4-hour restart cycle produces six files a day. On top of that, server-manager tools often relocate completed logs into archive folders at boot, and hosts' cleanup scripts routinely delete old ones after days — sometimes hours. The practical rule: if a log might matter, download it the same day. The number one irreversible admin mistake is deciding to investigate a three-day-old incident on a server that retains two days of logs. Archiving is one scheduled FTP pull; do it before you need it.

Anatomy of a line

Here is a real-format hit line, the densest kind you'll meet:

14:22:31 | Player "Vex" (id=Bk3vXHboAgimx4YjtUhIbeU4opowqglb7jg4O7AB4o= pos=<4757.2, 288.6, 10203.5>)[HP: 62.3] hit by Player "Rook" (id=Qm9dXHboAgimx4YjtUhIbeU4opowqglb7jg4O7AB4o= pos=<4611.0, 291.0, 10088.4>) into Torso(3) for 38.7 damage (Bullet_556x45) with M4-A1 from 186.2 meters

(Names and ids in every example on this page are invented.)

Reading left to right:

• 14:22:31 — time of day in server-local time, and only time of day. There is no date on any line; the date lives in the filename. If a player reports "I got killed around 9pm my time", you must convert through both their timezone and the server's before you search — the same conversion discipline as timestamps in a lag investigation.
• Player "Vex" — the in-game character name. Names are chosen by players, change freely, and collide. Never identify anyone by name alone.
• id=Bk3v…B4o= — the player's persistent identity, a Base64 string. This is not a Steam64 ID. It's a hashed identifier that stays stable for the player across sessions and name changes, so it's what you actually match on. The familiar 17-digit Steam64 ID (76561198…) shows up in many mod logs — killfeeds, codelocks, basebuilding mods — and admin tools correlate the two; the vanilla .ADM alone won't hand it to you.
• pos=<4757.2, 288.6, 10203.5> — position as <X, elevation, Y>: the first number is east-west, the third is north-south, and the middle one is height above sea level. To place a point on a map (iZurvive or any map tool), use the first and third numbers. Plotting the first two puts everyone on a line along the coast — the classic first-timer mistake.
• [HP: 62.3] — the victim's health after this hit.
• into Torso(3) for 38.7 damage (Bullet_556x45) — body zone (the number is an internal zone index), damage dealt, and the ammunition class. Melee shows Melee* damage types here instead of a bullet class.
• with M4-A1 from 186.2 meters — weapon and range. Melee hits usually omit the range.

Every other event type is a simpler arrangement of the same parts:

Placement and build/dismantle lines (from the two cfg flags) name the player, the object, and a position; basebuilding mods (BaseBuildingPlus and friends) write their own richer lines into the same file — often with the Steam64 ID and the tool used. Note the small format quirks: connect/disconnect lines have no pos= and no space before (id=, and a player who never fully joined disconnects as (id=Unknown).

Worked examples

A kill, read as a chain. A kill is never one line — it's a burst of hits ending in a kill line:

14:22:31 | Player "Vex" (id=… pos=<4757.2, 288.6, 10203.5>)[HP: 62.3] hit by Player "Rook" (…) into Torso(3) for 38.7 damage (Bullet_556x45) with M4-A1 from 186.2 meters
14:22:33 | Player "Vex" (id=… pos=<4758.0, 288.6, 10201.1>)[HP: 24.1] hit by Player "Rook" (…) into Torso(3) for 38.2 damage (Bullet_556x45) with M4-A1 from 184.9 meters
14:22:34 | Player "Vex" (DEAD) (id=… pos=<4758.1, 288.6, 10200.8>) killed by Player "Rook" (id=… pos=<4611.0, 291.0, 10088.4>) with M4-A1 from 186.2 meters

Watch the [HP: values count down — that's the fight's tempo. And note what the kill line doesn't say: the kill line carries no body-zone information. "Was it a headshot?" is answered by the last hit line before the kill, not the kill line itself. Both players' positions appear on every line, so you also get range and bearing for free.

A death with no attacker. No killed by Player line? The log still tells you what happened: hit by FallDamageHealth immediately before death means a fall; died. Stats> Water: … Energy: … Bleed sources: … is the environment's verdict — the stats line tells you whether they starved, dehydrated, or bled (a non-zero bleed count with earlier combat hits means the fight killed them slowly); bled out is explicit; killed by <creature> covers infected and animals. When a player insists "the server killed me", these lines settle it in their favor or not.

A suicide. Suicides get their own distinct line — committed suicide — not a kill line. If your community argues about K/D stats or a "mysterious death", check for this first; it also explains deaths at full health with no preceding hits.

Who was where. Search the file for a player's id= string and collect every pos= over the window in question — combat, placement, and (if you enabled adminLogPlayerList) the 5-minute roster dumps give you a breadcrumb trail. Plot first-and-third coordinates on a map and you have a movement track: good enough to confirm or demolish "I was nowhere near your base." This is exactly the kind of question — many players, one window — where counting beats arguing, the same instinct as scoping a lag complaint.

What the ADM cannot tell you

• Anything client-side. What a player saw, their FPS, their desync — the log records the server's rulings only. Why that distinction matters is the whole subject of how DayZ multiplayer actually works.
• Shots that missed. Only hits are logged. An ambush where nobody connected a shot is invisible.
• Loot and inventory actions. Vanilla ADM does not log picking up, dropping, or stashing items. Mods and the expanded flags add some of this; without them, "he took my gear" is unprovable from the ADM.
• Voice chat. Text chat is logged; VOIP never is.
• Steam64 IDs (vanilla lines carry the Base64 id only — see above).
• Anything before your oldest retained file. Rotation is a hard wall. No tool recovers a deleted log.

Traps (each one has burned someone)

• The date is in the filename, not the lines. A file that spans midnight ticks from 23:59:59 to 00:00:00 with no marker — naive scripts (and naive humans) put post-midnight events on the wrong day.
• Server time ≠ player time. Half of all "the logs are wrong" complaints are timezone math. Establish the server's timezone once and write it down.
• id= is not a Steam64. Pasting the Base64 id into Steam lookups gets you nothing; matching players by display name gets you the wrong person eventually. Match on the id, translate to Steam64 via mod logs or tooling.
• The middle position number is altitude. Map tools want the first and third numbers.
• The kill line has no hit location. Headshot claims are settled by the preceding hit lines.
• Occasionally the killer field is blank — a line reading killed by with <weapon> from … meters, an engine artifact. The preceding hit lines identify the attacker.
• Names carry decorations in some lines — suffixes like !DEAD or a respawn counter (2) can be glued onto names. Another reason to search by id, not name.
• Formats drift between game patches. A search snippet or script that worked last year may quietly miss lines today. When something "isn't in the logs", scan a raw file with your own eyes before concluding it didn't happen.

By hand, or with tools

Everything above works with a text editor and Ctrl+F — that's the point of this guide, and for a single incident it's genuinely the fastest path: download the file, search the player's name once to grab their id=, then search the id. Log-analysis tools — ADM upload analyzers, map plotters, and live platforms that parse the files continuously — automate exactly this reading, which is why learning the raw format first pays off: you can sanity-check any tool's summary against the line it came from (our own dashboards do this parsing live, and we still open raw files weekly). The tool changes; the .ADM line is the evidence.