Skip to main content

Server diagnostics

DayZ writes complaints about your configuration into its own log and then carries on without you. This page collects those complaints, so a broken types.xml entry or a custom file the game never loaded becomes something you can see and fix.

Navigation path:

  • Server Admin → Diagnostics

Access requirements​

  • admin.game_audit.view — open the page. Labelled View Server Diagnostics.
  • admin.game_audit.edit — mark findings as fixed, ignore them, stop ignoring them. Labelled Mark Server Errors as Fixed.
Nobody was given these rights automatically

There is no backfill command for them. A group holding individual admin.* keys rather than the admin.* wildcard sees no diagnostics page until you grant the rights by hand.

Where the findings come from​

The source is the RPT log — the server's own engine log, not the ADM log that feeds the Log Explorer. The log import runs once a minute for every server with a working Nitrado link.

A line is picked up when the engine marked it itself with !!!, or when it matches one of a handful of phrases that are known to mean trouble without carrying the marker — a missing classname, a failed preset load, an obsolete element.

There is deliberately no fixed catalogue of error types. An early attempt with a curated list of eight patterns caught four of eighty-eight real-world problems, so the parser is generic instead: it splits each line into its area, its subject and its message, and keeps the message as the game wrote it.

Identical problems collapse into one entry. Numbers, coordinates and quoted values are masked before comparison, so fifty-nine failures of the same spawn at different positions become one finding with an occurrence counter, not fifty-nine rows.

Highlighted findings​

A small set of patterns is highlighted on the page and labelled Error. These are the problems where the game is definitely not doing what you configured:

  • a type in types.xml that DayZ does not know, or cannot spawn
  • a value or usage not defined in cfglimitsdefinition.xml
  • an event in events.xml or cfgeventspawns.xml that failed validation or was disabled
  • a custom object-spawner file the game could not load
  • a preset in cfgspawnabletypes.xml the economy ignores
  • the economy spawning none of the amount you asked for
  • a deprecated element, which means the game runs on its default instead of your setting

Everything else that qualifies is listed as a Note.

Two kinds of finding are listed as a note even though they match one of the patterns above:

  • Mistakes in Bohemia's own mission files. A server whose files were never touched still reports the missing VehicleTransitBus event, the unknown Static_FrozenScientist_DE, the Christmas trees and, on Livonia, the misspelled WinterMilitaryCoat_Greay. They are harmless, and a fresh server should not greet you with errors.
  • Partial spawn failures. "3 < 4" means three of four spawned and one position was blocked — usually by a player standing nearby. Only a spawn that produced nothing at all counts as an error.

Working through a finding​

Each finding has three actions:

  • Fixed — you have changed the configuration. The finding moves out of the unfixed list.
  • Ignore — keeps counting and keeps showing as unfixed, but moves out of the open list. This is for errors coming out of a mod you do not maintain yourself.
  • Stop ignoring — undoes that.

Two behaviors are worth understanding before you rely on them:

  • A fixed finding comes back if the problem does. It reopens only when a newer log line matches it, so re-importing older logs does not resurrect it.
  • An ignored finding never reopens by itself. Its counter and last-seen keep moving underneath, but it stays ignored until you say otherwise.

DayZ reads types.xml, events.xml and the rest only when it boots. Editing a file therefore changes nothing on this page until the next restart produces no matching line. Marking something fixed before that restart is a note to yourself, not a verification.

Prerequisites​

  • A working Nitrado link is mandatory. The RPT log is fetched through Nitrado, so a server whose authorization was revoked stops collecting findings — silently. See Nitrado setup.
  • The server must not be switched off in dzbot.
  • Findings appear only after a log import has run and found RPT content. There is no manual trigger on the page.

There is no subscription gate; the access right is the only gate.

Things that are deliberately not shown​

  • Subscription spawns. A shop subscription that failed to spawn looks like an ordinary spawn failure in the RPT, but it never appears here. It is handled on its own path — the buying player is refunded automatically and the failure is raised as an event you can act on. See Shop system. The position and the fix belong to that player's order, not to your configuration.
  • "NO VALID SPAWNS" at startup. The engine logs it before map data is loaded, well before anyone spawns. It reads like a catastrophe and means nothing.
  • Bare XML parse-error counts. The game reports that it failed to parse something without naming the file or the line. There is nothing to act on, so these are filtered rather than listed as unactionable noise.