How we read this

The one rule

We never publish a number we cannot trace to its source. Game facts (stats, costs, damage, cooldowns) come from the game's own files, or from the game's own formula over those files and marked as computed. Match statistics (how often one hero beats another) come from a named source, always with their sample size, rank range, patch and dates, and are never mixed into a game fact. No fan-site data, no guessed values. If no source has a fact, the page says so rather than filling the gap.

Pull the build

We read each build from SteamDB's GameTracking-Deadlock repository on GitHub, a public third-party archive that commits the text of every Deadlock client build, one commit per build. We read the game's data files at that build's commit, table by table, and hash every table so a re-read is verifiable. The Source on every page's build stamp links to the commit its numbers were read from, so you can check any number against the client's own text. Game facts come from the build's files, never a fan site or wiki; the few engine rules the files lack, such as the 12-item cap, are under Computed stats with their source.

Diff every table

Each build is compared against the one before it, keyed on the entity's own stable id, not on a row number that shifts between builds. Engine noise that no player can see is counted apart from a change a player can feel, so a verdict of buffed or nerfed means what it says. A change counts as file-only when no tooltip reads any differently: a stat the client adds or drops at 0 (unless what it scales with moved, since an upgrade can grant it), a style class or flag, an item disabled on a hero nobody can pick yet, the file's other degree sign, a stat moved to a new key with the same label and value, or a tooltip that only reorders its lines. A patch page counts those and lists everything else with both values. Its Change column is arithmetic over the two values it prints, shown only when both carry the same unit: percentage points for a percent value, the plain difference when either side is 0 or negative, and otherwise the percent of the old value. A number with thousands separators reads as the number, so 3,200 to 4,000 is +25%. It is the one number in the table we compute. The headline numbers above the table are picked by a fixed rule: first, up to 3 rows the game marks as leading (an item's price), then the 3 largest other moves, ranked by the change relative to the larger of the two values, one per record, ties in table order. The ranking is computed; the values it quotes are the table's own.

Publish every record, changed or not

Every entity a player can obtain or use gets its own page, stamped with the build it was read from and the date it was read. Rows the client marks unused or unreleased get no page until the game shows them to players. A row whose page would be thin, with no numbers and no relations, gets a page that search engines are told not to index.

How the shop planner buys an upgrade

In the shop planner, as in the game's shop, buying an upgrade consumes every owned item in its component chain and takes the first one's slot, and its price drops by what those items cost. Own Close Quarters and buy Point Blank, and Close Quarters leaves its slot and 800 souls come off the price. The same holds further down the chain: own Extra Spirit and buy Boundless Spirit, whose file names only Improved Spirit, and Extra Spirit leaves its slot and Boundless Spirit costs 800 less. The files name only the direct component, so this chain rule was confirmed in the game's shop on September 30, 2026. Owning an upgrade also means nothing below it in its chain can be bought back on top.

How a corrupted total is computed

On the corrupted items and each corruptible item's page, the bonus is the file's own value. The "corrupted" total beside it is computed: the item's value plus the bonus, because the game's schema says a bonus with no upgrade type adds to the base value. The Broker also moves most bonuses by a random amount each match; the files mark which bonuses are fixed but not how far the others move, so we never print a varied value.

Match statistics

The "counters", "most-bought build" and "ability order" sections on each hero page, the "in matches" and "Heroes who buy" sections on each item page, the "in matches" section on each ability page, and the measured columns on the heroes and items lists are measured, not read from the game files. They come from deadlock-api.com, which collects completed Deadlock matches. We download one snapshot of hero and item statistics with a separate command, never during the site build, and commit it with the exact queries, the time we fetched it, the patch and every match count, so each number can be checked against the source.

The window starts on the release day of the newest patch that changed a hero, ability or item and runs to the last full day (UTC) before the download. It counts normal-mode matches at all ranks, and every match where the two heroes were on opposite teams, not only lane opponents. A hero's win rate against an enemy is the matches it won against that enemy divided by the matches the two played on opposite teams, rounded to one decimal.

The lists are not ordered by that rate alone, because a hero that wins most of its games would top every other hero's list. Instead each pairing is compared with the rate the log5 formula expects from the two heroes' overall win rates in the same window: "Toughest matchups" lists the five pairings furthest below that expectation and "Best matchups" the five furthest above it, ties going to the pairing with more matches. Beside each measured rate the table prints the expected rate and the gap between the two, both labelled computed: the expected rate is rounded to one decimal, and the gap is the exact difference in percentage points, rounded to one decimal only at the end, so the gaps read in the same order as the list. That means a printed gap can differ by 0.1 from subtracting the two rounded rates. The rate you see first is still the measured one. When either hero's overall record is missing from the snapshot, that hero's lists fall back to the lowest and highest measured rates and print no expected rate. An overall record under the minimum sample still orders the lists, but its expected rate is not printed. A pairing needs a minimum number of matches to show a rate, and each counters section prints that minimum; below it the page says "not enough matches". Every rate is printed beside its match count, and the section names the rank range, patch and dates it covers.

An item's win rate is the matches won by players who bought it, divided by the matches they bought it in, over the same window, mode and ranks. It describes the players who bought the item, not what the item itself adds: an item players tend to buy when already ahead can show a high win rate for that reason alone. Its buy rate is the matches in which a player bought it, divided by every player in every match of the window (each hero's match count from the same download, added up), so a buy rate of 2% means 2 in every 100 player slots. The buy rate is shown only when both counts come from the same window, mode, ranks and patch. Both count normal purchases only: the Broker can swap a tier 3 or 4 item for a corrupted copy, and those corrupted purchases are left out, because the source counts them from a different, smaller set of matches than the rest. The same minimum match count applies; below it the item page says "not enough matches".

The "most-bought build" section of a hero page splits the items bought on that hero into three tables by when in a match they were bought: laning (bought before 10:00 of game time), mid game (bought from 10:00 to 19:59) and late game (bought at 20:00 or later). Each table comes from its own download of the same per-hero item numbers, limited by deadlock-api.com to purchases made in that span of game time, over the same window, ranks, mode and patch as every other number here, and lists the six items bought in the most of the hero's matches in that phase, ties going to the item name. Its "bought by" rate is the hero's matches in which the hero's player bought the item in that phase, divided by every match the hero was played in over the window, including matches that ended before the phase began, since the source does not count the matches that reached it; so 40% means the item was bought in that phase in 40 of every 100 matches of that hero. Its win rate is how often those players won. Like any item win rate it describes the players who bought the item, not what the item adds. The average buy time is the average game time of those purchases, measured by deadlock-api.com and rounded to the second. The tables are the most bought items, not a recommended build. An item needs the same minimum match count on that hero in that phase to be listed; when none does, that table says "not enough matches". Each table's "Open these in the shop" link loads its items into the shop in that order, under the shop's own rules (an item the game disables for the hero, or a component an upgrade on the list already covers, drops out), at the level the souls in those items reach on the hero's soul curve. The button under the hero page's opening, "Open the most-bought build", loads the first four items of each table, laning then mid game then late game, the same way, and the line under it names the hero's match count and the window. The section's opening sentence and its question and answer name the three items bought in the most matches over the whole match, from the same download split by hero without the game-time limit. The "Heroes who buy" section of an item page shows the same per-hero numbers turned around by item, with the same "bought by" rate and minimum, listing up to eight heroes ordered by that rate, highest first; it is the heroes that buy the item most often, not a recommendation.

The "ability order" section of a hero page shows the orders players unlock that hero's four abilities in, from the same source, window, mode and ranks, downloaded one hero at a time. The source lists every full sequence of ability points; we keep only the order of each ability's first point, so two players who unlocked the abilities in the same order count as one order however they spent their later points. An order's share is the matches that used it divided by every match of the hero the source counted for this view, including players who spent no ability point, rounded to one decimal. That total comes from the ability order download itself, not from the hero win rate download, because the two do not count exactly the same matches. The section names the most used order and the runner-up; an order needs the same minimum match count to be named, and below it the section says "not enough matches". Each ability page shows the same numbers turned around: at which step of the order (first, second, third or fourth) players unlocked that ability, each step with the share of its hero's matches that unlocked it there; a step needs the same minimum match count to be listed. The most common order is what players did, not a recommendation.

deadlock-api.com is not endorsed by Valve and does not reflect the views or opinions of Valve or anyone officially involved in producing or managing Valve properties.

Reusing the data

Free to reuse with attribution to Deadlock Shop; the game data belongs to its publisher. Every patch page links its changes as JSON, the same file its Dataset markup names. You may republish those numbers if you credit Deadlock Shop. The game's names, text and art remain its publisher's; we claim no affiliation.

What we do not claim

Drop rates, drop locations, vendor prices and loot chances live on the game's servers, not in the client, so we do not state them. Where a page would be expected to, it says plainly that the game files do not contain that fact.