Tracing an Item: Reading Its History and Its Id

"Where did my gun go" and "who emptied my stash" both start the same way: find the item, then read its story. This guide covers the Items pages — search, the per-item history, the map search, and the container panel — and the one thing that trips people up on all of them: an item's id is not always the same kind of promise.

Why an item can have two different ids

The game engine tracks every item with an internal id. Two things make that id less useful than it sounds:

• A server restart reissues it. The id an item had yesterday afternoon means nothing after tonight's restart — a completely different item can get the exact same id tomorrow.
• A player relogging reissues it too, for anything that player is holding, even without a server restart.

So a bare id, on its own, only proves "this was one item for some stretch of time" — not "this was one item all wipe." dayz.fyi tracks three different strengths of identity, weakest to strongest, and shows you which one you're looking at with a small colored badge next to the item's id wherever it appears (search results, the item's own page):

Hover the badge on any page for the same explanation in one line.

Why doesn't everything get a persistent id? Right now, only completed inventory moves (an item being dragged from one place to another) carry it. Picking an item up off the ground, and equipping or dropping something in your hands, do not — yet. That is a known gap in the upstream mod, tracked and asked for, not a dayz.fyi limitation. Until it lands, most items you look up will show the network or boot badge rather than persistent, and that is expected, not broken.

What "stitched by time window" means

When an item's history page shows a note like "3 rows stitched by time window," it means: those rows didn't carry a persistent id themselves, but they fell inside the same short time span as rows that did, for the same item — so the page attributed them to the same item rather than showing a gap. It's a reasonable inference, not a certainty. If you see a long quiet gap in an item's history with no persistent id anywhere in it, treat what comes after the gap as possibly a different item that reused the same network id — the page will call this out when the gap is long enough to be suspicious.

Searching for an item

The search box on the Items page accepts three different kinds of input, and figures out which one you typed:

1. A classname (e.g. AKM, TravelBackpack_Blue) — matches every item of that type observed this wipe.
2. An item id, either kind — paste an id from anywhere else in the product (a log line, a detection, a link) and it goes straight to that item, no need to know which kind of id it is.
3. A player's Steam64 id — lists that player's own item observations directly. (This search mode may not be available on every server yet; if the search box doesn't return player rows for a Steam64 you know is right, it hasn't been enabled there.)

What the map search needs, and why

The map search (the fenced-area item search) requires three things at once: an item or classname, a fenced rectangle on the map, and a time window. It will not run with only one or two of those — you cannot ask it "show me everything that happened around this spot" with no item and no time bound.

This is deliberate, not a missing feature. Item interactions happen constantly, everywhere, on a live server — an unbounded query over "everything near this point, ever" would have to scan far too much data to answer quickly, and would make every other page on the server slower while it ran. Narrowing to one item and one window keeps every map search fast for everyone. If you don't know the item yet, start on the item's own history page instead — it doesn't need a fence.

What's kept, and for how long

Two different retention windows apply, and they affect different questions:

• Completed moves (an item being dragged between inventories, containers, or the ground) are kept for 45 days, and are read per item — the history page pulls every kept move for the specific item you're looking at, not "everything in the last 45 days." An item you haven't looked at in two months has aged-out moves you won't see; anything more recent than that is there. The server Logs feed also has a "Custody changes (moves)" option: it lists moves that changed who held an item (ground, a player, a container) newest first, with since/until and paging, and says the date its record starts, so anything before that date is still only on the item's own page.
• Pickups and hand equips/drops are kept for the whole current wipe (plus the prior one), not on a rolling day count. A long-running wipe keeps all of it; a wipe reset clears it the way any wipe reset clears wipe-scoped data.

If an item's history looks like it has a gap, check which kind of gap it is — a 45-day move gap behaves differently from a wipe boundary.

The container "recorded in / out" panel

Where it appears (an item's own page, and a base's page when the container is tied to it), this panel lists moves that changed a container's contents — labeled "recorded in / out," not "contents," on purpose:

• It shows only moves the platform actually observed. A container being dragged onto the ground, or dragged directly into another container, with no player holding anything at either end, produces no attributable event — there's no "out" row for that kind of move. If a chest looks emptied with no corresponding "out" entries, that is the likely explanation, not a bug. It never means "nothing happened."
• A container without its own persistent id has no ledger at all — no in/out history exists to show, regardless of what actually happened to its contents.

Read it as "what we can prove moved," not as a live inventory of what's inside right now.

"Last recorded inside" on the container page

The container's own page (Activity → Containers, then a container) also has a "Last recorded inside (reconstructed)" list above the in/out history. It is the closest thing to a contents view the platform can give today, and it is rebuilt from the recorded moves, not read from the server: every item whose most recent recorded move at this container was a move in, with no later recorded move out. Each row links to the item's own page, with who put it in and when.

Use it as a lead — "these items were last seen going in here" — and check the item's own page before acting on it. It inherits every gap of the in/out history, so it can be wrong in both directions:

• It can list items that already left. A drag from the container straight to the ground, or into another container, isn't recorded, so the item still looks inside.
• It can miss items that are there. Anything already inside before recording began, or spawned, crafted, or given inside the container, never had a move in. Items without a persistent id can't be followed at all, and the contents of a bag or case inside the container aren't listed on their own.
• Stack sizes aren't tracked. Splitting or merging a stack isn't recorded.
• Very busy containers stop early. The record keeps a container's first 5,000 moves; past that, the panel says so and the list shows the container as it stood back then.
• Recording can be off. If item-move recording isn't active on the server, the page says so and anything moved since is missing.

A row marked "order uncertain" is an item taken out and put back within a few seconds where the order of the two couldn't be worked out — it may or may not still be inside.

The item-stream coverage chip

Item pages show a small chip per event stream (pickups, hand equips/drops, completed moves) with one of three states:

• Live — a row arrived recently. The stream is working for this server right now.
• Stale — rows exist for this wipe, but not recently. Something may have stopped working, or the server may simply be quiet.
• Never — no rows at all this wipe. This does not necessarily mean nothing happened. It usually means the underlying stream isn't turned on for this server, or the server hasn't been reporting — not that the game produced no item activity. Before concluding "nothing was picked up here," check this chip.

An empty search result and a "never" chip together mean "we can't tell you," not "it didn't happen."

When to stop and escalate

The Items pages answer "what happened to this item and who touched it" — they are a history reader, not a verdict. If what you're looking at makes you suspect duplication, spawning, or another form of cheating, that judgment call belongs on the Detections page, where signals are corroborated before they're presented as a finding. Don't treat a single unusual-looking item history as proof on its own — hand it to Detections, or gather a second independent signal, the same way Catching cheaters recommends for any other suspicion.

Traps

• Treating a network-id item's whole page as one item's history. Without a persistent or boot badge, a long enough page may in fact be two or three different items that shared a recycled id. Check the badge before you narrate a "story" from the page.
• Reading "never" on the coverage chip as "no activity happened." It usually means the stream isn't reporting, not that the server was quiet.
• Assuming an empty container "recorded in / out" panel means nothing was taken. Container-to- ground and container-to-container drags are invisible to it by design, and a container with no persistent id has no panel data at all.
• Expecting the map search to answer an open-ended "what happened here" question. It needs an item and a time window; use the item's own history page for open-ended browsing instead.
• Confusing the two retention windows. A quiet stretch in an item's move history may just be outside the 45-day move window, while its pickups and hand history for the same period are still there for the whole wipe.