DayZ Admin Logs: What the Vanilla `.ADM` File Records—and What It Cannot Prove

An .ADM file can settle some DayZ questions quickly: who connected, what a damage line says, whether a configured base-building action was logged, or where a five-minute player snapshot placed someone. It cannot turn a server into a replay. The useful reading starts by identifying the file, checking the launch and configuration gates, and then treating every line as a bounded event rather than a complete account of a survivor’s actions.

Before interpreting an excerpt, confirm which vanilla stream it is, which optional categories were enabled, and how much of the file the admin shared. Those details determine what the lines can support—and what a gap cannot.

What Counts as the Vanilla .ADM File—and Where It Lives

Before you treat a shared line as evidence, identify the file behind it. The vanilla .ADM is DayZ's server-side administration stream: output produced by the game's built-in logging system for the events that vanilla exposes. It is not a general-purpose record of everything happening on the server, and a server-side mod's extra log is not automatically part of the vanilla format.

A hosted log viewer showing the executable-named .ADM file and AdminLog entries.

The global gate is the -adminlog launch parameter. The server must start with that parameter for vanilla admin logging to be enabled; having a configuration file or opening a host panel does not replace the launch requirement. The separate -config parameter chooses which configuration file the server reads, so that file does not have to be literally named serverDZ.cfg. Its filename and the .ADM filename are separate concerns.

For a dedicated server, the naming rule is simple: take the server executable's name and append .ADM. In the general form, the file is server_exe_name.ADM, and it is created in the profiles directory selected by -profiles. DayZServer_x64.ADM is a useful historical example of that rule, not a filename you should assume every host uses today. If you manage a PC server, start with the exact -profiles path in the launch command rather than searching the installation directory at random.

Hosted servers may hide that filesystem layout. A provider can expose the file through a log viewer or file browser, offer a download, rotate the visible copy, or make a newly written file available only after a restart. Panel labels and paths differ by provider, so a download that does not visibly show the -profiles directory is not necessarily the wrong file. Ask the admin which log was exported, what time range it covers, and whether the panel had restarted or refreshed it before sharing it.

Keep the neighboring log names separate when someone hands you a bundle of files:

That distinction gives you a concrete first check. Suppose a PC owner starts the executable with -adminlog and points -profiles at a dedicated profiles folder: the expected vanilla artifact is an executable-named .ADM file in that folder. A hosted owner might instead send you a download from a provider's logs view. By contrast, an .RPT attachment or server_console.log may be useful for a different investigation, but it does not answer the same question. Once the file's identity, source, and covered time window are confirmed, the next question is which server settings determined what could enter it.

Which Settings Decide What the File Can See

Once you have identified the file, match the question to the optional control that could have produced the relevant line. These controls are independent: a server can record player hits without recording placements, or take five-minute player snapshots without recording base-building actions.

The current public configuration reference shows all four adminLog* values as 0. Read those values as the reference's example or baseline, not as a live-status report for every community server. A host preset, an owner's edits, or a panel's saved settings may differ. If an admin shares an .ADM excerpt, the relevant setting must be confirmed separately before you treat the presence or absence of an optional line as meaningful.

The four adminLog* controls

adminLogPlayerHitsOnly changes the scope of hit entries rather than enabling or disabling the other event classes. With adminLogPlayerHitsOnly=1, hit logging is limited to player hits. With adminLogPlayerHitsOnly=0, it includes all hits, including damage from animals and infected. That distinction matters when a report concerns a wolf or infected: a file configured for player hits only is not expected to contain those documented animal/infected hit entries.

adminLogPlacement=1 enables placement actions such as placing traps and tents. Keep this tied to the placement question itself. It does not mean the file is an inventory ledger or that every item moved through a container will appear there. With the setting at 0, a player looking for a trap or tent placement should not assume that a blank interval proves the placement never occurred.

adminLogBuildActions=1 enables base-building actions such as building, dismantling, and destroying. This is the switch to ask about when a dispute concerns a fence or another logged building action. It does not automatically expand the file into a record of every raid step, lock interaction, damage event, or inventory change; those are separate questions from whether the building action itself was enabled for logging.

adminLogPlayerList=1 enables a periodic player list with each listed player's position. The snapshot is emitted every five minutes. It gives an owner or investigator useful position checkpoints, but not a continuously updated route: two snapshots show where the player was at those moments, not every movement between them. If the setting is 0, the absence of a player-list block is expected even if other admin-log categories are active.

Match the question to the setting

For example, if you are checking an alleged base breach and the excerpt contains no built, dismantled, or destroy line, first ask whether adminLogBuildActions was set to 1 during the relevant period. If you are checking a trap placement, ask about adminLogPlacement instead; the two switches do not substitute for each other. For a location question, use adminLogPlayerList to identify five-minute checkpoints and do not turn the gaps between them into a continuous movement story.

Hosted-server changes need the host's workflow

On a dedicated server, the owner edits the configuration used by the launch command. On a hosted server, the same choices may appear as checkboxes with different labels, or may be hidden behind the provider's settings and log pages. The safe operational pattern is to select the needed log options, save them, and restart the game server if the provider requires a restart before applying them. A host may expose the result through a log viewer or download rather than the underlying configuration file, and its file-browser path is provider-specific.

A server owner enables the needed categories through the host's documented save/restart process and reports which settings were active and what time window the file covers. A player can then classify the visible lines against the documented event families instead of assuming that every optional class was recorded.

What the Documented Vanilla Event Stream Records

The current public configuration reference corroborates the four adminLog* controls, while the official Administration Logs event table is explicitly a patch 1.02 reference. The families below are the documented vanilla vocabulary, not an exhaustive guarantee of every 1.29 internal event. Group them by the evidence they provide: identity and presence, communication, combat and health, world actions, and periodic position snapshots.

Identity and presence

The basic presence events are player connections and disconnections. These lines record a player joining or leaving the server’s session, giving an administrator a server-side event for the beginning or end of that connection. They belong to the built-in stream rather than to a server-side logging mod’s expanded schema.

Communication and reports

Vanilla ADM also documents player chat lines. The examples include the player’s name and ID alongside the message, making the event useful for identifying what was sent through the logged chat channel and when it appeared in the stream.

Reports submitted through the in-game #toadmin chat form are a separate documented communication family. That distinction matters in an investigation: a report sent through the game’s admin-report path is not the same evidence as a private Discord message, a ticket on a community website, or a moderator’s later summary. The ADM line represents the report event that reached the server’s built-in logging path.

Combat and health events

The combat portion of the documented stream is more detailed than a simple “player was hit” marker. A damage line can include:

The examples cover different causes rather than only player-versus-player fire: another survivor, an animal or infected-like source such as a wolf, fall damage, and fire from a fireplace are all represented in the documented event set. The adminLogPlayerHitsOnly filter changes which of those hit lines can appear. With adminLogPlayerHitsOnly=1, the hit stream is limited to player hits; with 0, it includes animal and infected hits as well. That setting changes hit coverage, not the meaning of the other event families.

The same combat and health group includes consciousness transitions. The documented events record a player becoming unconscious and later regaining consciousness. This can establish that those state changes were logged, while the accompanying damage or death families supply different kinds of information.

Death lines have several documented forms. A player-versus-player or other source death can identify the source, weapon, and distance where those details are available. The event table also includes a generic death status, suicide, and bleeding out. Some generic death entries carry status information such as water, energy, or bleeding-source state. A death line therefore identifies a death event and the details that particular form records; it is not a complete reconstruction of every action or injury that led to it.

World-action events

Placement and base-building lines are optional additions to the core stream, so their absence or presence must be tied to the relevant configuration control.

When adminLogPlacement=1, the documented placement family can record actions such as placing a bear trap, fireplace, or tent. These are world-action events: they show the logged placement action, not a universal accounting of every object a player carried, moved, dropped, or transferred.

When adminLogBuildActions=1, the documented build-action family can record actions such as building or dismantling a fence. The configuration description also names destroying as a supported base-building action. The useful evidence is therefore the logged actor and the building action represented by that line; it should not be expanded into a promise that every lock interaction, raid step, damage event, or inventory change shares the same entry.

Periodic player-position blocks

adminLogPlayerList=1 adds a different shape of evidence: a periodic player-list printout containing the number of players and each listed player’s current position. The documented interval is every five minutes. This gives the file a set of position checkpoints alongside its event lines, rather than turning it into a continuously refreshed movement record.

The distinction between these families is practical. A connection line concerns a session event; a #toadmin line concerns a submitted report; a damage or death line concerns combat or health; a placement or build line is conditional on its world-action flag; and a player-list block is conditional on its five-minute snapshot flag. Classifying the line by family keeps the claim proportional to what the server says it recorded.

The documentation boundary

Classify a visible line by family and record only the event and fields it actually contains; then use the reading order below to build a bounded timeline.

How to Read a Shared .ADM Excerpt Without Overreading It

The safest way to read an excerpt is to turn it into a bounded timeline, one line at a time. Start with the same anchors every time: the HH:MM:SS timestamp, the event verb, the player name and repeated id=, the pos=<x,y,z> value, and the fields that belong to that event. Then compare the line with its neighbors and with any nearby five-minute player-list snapshot. This tells you what the server recorded at a point in time without turning one entry into a complete story.

Use the same reading order for every line

1. Timestamp: Record the HH:MM:SS value first. It places the event in the excerpt’s server-time sequence. A timestamp orders the lines you received; it does not by itself tell you how much of the surrounding log was omitted.
2. Event verb: Identify what happened in the line—such as a connection, hit, death, placement, build action, or PlayerList printout. The verb determines which fields are relevant and stops you from reading a combat field into a construction event.
3. Player and ID: Note the displayed player name and the id= value. When the same ID appears again, it helps you correlate that line with the same logged identity elsewhere in the excerpt, even if the name changes or several players have similar names. The available reference does not establish a platform-specific conversion from that value to a DAYZGUID, nor does a repeated ID alone prove an account identity outside the log context.
4. Position: Capture pos=<x,y,z> when it is present. Treat it as the position associated with that recorded event or snapshot. You can paste the coordinates into a compatible map tool as a practical aid, provided you select the correct map; do not infer a map URL, axis convention, or route from the coordinate alone.
5. Event-specific fields: Record only the payload that belongs to that event. A hit may include health, hitzone, component, damage, ammunition, weapon, source, and range. A build line may identify the action and the actor. A player list gives a roster and positions. “Not present” is different from “zero” and from “not applicable.”
6. Nearby context: Read the preceding and following lines before drawing a conclusion. A connection, hit, unconsciousness change, death, placement, or build line can change how you interpret the next event. A nearby PlayerList block can provide a checkpoint, but it cannot fill in every moment between checkpoints.

This order also keeps repeated IDs useful without making them carry more weight than the evidence supports. You are correlating strings inside the shared file, not performing an account-ownership lookup. If the admin needs to connect a logged ID to a player outside that excerpt, ask for the server’s identity context rather than treating the ID format as self-proving.

Example: walk a PvP hit line field by field

Suppose an excerpt contains a hit entry at 18:42:11 with a victim name, a repeated id=, a pos=<x,y,z>, current HP, an attacker or other damage source, a hitzone and component, a damage value, ammunition and weapon details, and a ranged-hit distance. Read it in this order:

• 18:42:11 places the hit in the local sequence you are examining.
• The victim name and ID identify the logged target; compare that ID with other lines before treating later entries as belonging to the same logged identity.
• pos=<x,y,z> locates the event as recorded. It is a point associated with the hit, not a path showing how either player reached it.
• Current HP, hitzone, component, and damage describe the recorded effect. Keep the damage number separate from the later question of whether the victim died.
• The attacker or source, ammunition, weapon, and range describe the source details that this particular line supplies. If one field is absent, do not fill it from a guess or from a neighboring player’s entry.

That reading supports a precise statement: the excerpt records a hit involving the named players or source, at the logged time and position, with the listed damage details. It does not by itself reconstruct the whole firefight, establish every preceding shot, or decide a community’s server rules. For a rule or ticket decision, use the server’s own requirements and the evidence it accepts; this section’s job is only to keep the ADM interpretation proportional to the line.

Contrast a build action with a position checkpoint

A base-building dispute uses a different line shape. If the excerpt contains built, dismantled, or destroy, read the logged actor, repeated ID, timestamp, position, and named action. That is useful evidence of the recorded building action only when adminLogBuildActions=1 was active for the relevant period. It is not a verdict on who owned the base, whether the action was allowed, or what other raid activity occurred. A trap, tent, or fireplace entry follows the same field discipline but belongs to placement logging and depends on adminLogPlacement=1; it should not be read as an inventory ledger.

Now compare that with a PlayerList block. When adminLogPlayerList=1, the file prints a player list with positions every five minutes. Treat each block as a checkpoint: record the time, the listed players, and each position, then compare it with nearby hit, death, placement, or build entries. If one checkpoint shows a player at one position and the next shows them elsewhere, the excerpt supports those two observed points—not the continuous route, stops, presence, or actions between them.

The practical result is an annotated sequence with clear limits: time, event, logged identity, position, and the fields that event actually provides. When you send questions back to the admin, ask which flag was active, what time window the excerpt covers, and which specific line supports the claim. That produces a defensible timeline without asking a shared .ADM excerpt to prove more than it records.

When the File Is Silent, Ask What It Could Not Record

An empty interval needs a coverage check before it becomes evidence. A missing line may reflect the file's time window, a disabled logging gate, partial export or retention, or an action outside the categories the vanilla reference promises.

A hosted file list illustrates why the exported log and its retention window need context.

What vanilla ADM does not promise

The documented vanilla stream also does not promise a complete record of these categories:

These are evidence limits, not a claim that no later feature or server setup could ever add such records. A placement line can establish a logged trap, tent, or fireplace placement when the placement logging was enabled; it does not turn the file into an accounting of the item’s prior inventory path. A build line can establish the recorded build, dismantle, or destroy action when the build-action logging was enabled; it does not establish every raid step, lock interaction, damage event, or ownership claim.

When another log is the real evidence

Server-side mods can extend logging, but their output is a different evidence stream. A mod such as MoreAdminLogs can write its own .log or .ljson files and add movement, more frequent positions, vehicles, gear, hands, crafting, item, and extended action categories. Those files have their own names, configuration keys, and schema; they should not be read line-for-line as if they were the vanilla executable-named .ADM file.

If the server is modded, ask the admin which mod produced the extra file, provide that file for the relevant period, and provide the mod’s schema or configuration. A mod’s movement or inventory entry may answer a question that vanilla ADM cannot, but only within that mod’s version, settings, and retention window. Do not use the presence of a similarly named “admin” file to silently expand the vanilla contract.

Technical problems should be routed separately. Use the server RPT for startup failures, mod loading, signature checks, and hard crashes; use script logs for Enforce Script errors and many mod-side failures; use the client log for a problem occurring on the player’s machine. An ADM excerpt may show gameplay events around a failure, but it is not the right diagnostic record for explaining why the server failed to start, rejected a signature, threw a script error, or produced a client-side fault.

The missing-line diagnostic card

Suppose an admin shares an ADM excerpt from a base dispute and there is no built, dismantled, or destroy line. Before treating that absence as proof that the action did not happen, check the four conditions below:

1. Global gate: Confirm the server was launched with -adminlog during the relevant period. The configuration file alone does not establish that the vanilla stream was enabled.
2. Relevant filter: Confirm adminLogBuildActions=1 was active while the action could have occurred. A different adminLog* setting, such as placement or player-list logging, does not substitute for it.
3. Time coverage: Compare the alleged action time with the first and last entries in the supplied file. Check for a restart, rotation, or an excerpt that begins after the disputed event.
4. Export and retention: Ask whether the copy came directly from the -profiles directory or from a provider viewer/download, and whether the host refreshed, truncated, rotated, or retained only a limited period of the file.

If any check fails, the correct conclusion is only that this copy cannot answer the base-building question. If all four checks pass and no matching line appears, the excerpt is stronger evidence about what the configured vanilla stream recorded, but it still should be phrased as “no matching line appears in the covered file,” not as an absolute reconstruction of what happened outside that stream.

Use the same discipline for other absences: verify adminLogPlacement before interpreting a missing trap or tent line, verify adminLogPlayerList before treating missing position blocks as meaningful, and verify the hit filter before drawing conclusions from missing animal or infected damage. Then request the evidence stream that matches the unresolved question: the raw or correctly exported ADM for vanilla events, the mod’s own file and schema for mod-added categories, or RPT/script/client logs for technical failures.

Before filing an accusation or exoneration, send the admin a precise request for the -adminlog state, the relevant adminLog* value, the file’s covered timestamps, and its export or retention context. If the question concerns a mod, request its separate schema-backed log; if it concerns a crash, signature rejection, startup failure, or script error, request the corresponding RPT, script, or client evidence before deciding what the record supports.