The same server, checked on three sites at the same moment, shows three different player counts. None of them is broken and none is lying. They are answering slightly different questions and presenting the answers identically.
The count is a reading, not a subscription
Nothing streams a player count to a directory. Each one asks the server, on its own schedule, and stores what came back.
That means every number you read is a timestamp with a value attached, and the timestamp is usually not shown. A site sweeping every fifteen minutes and one sweeping hourly will disagree for up to an hour after anything happens, and both will be correct about the moment they asked.
The first question about any discrepancy is when each side last looked. It resolves most of them immediately. The sweep interval here is fifteen minutes, stated deliberately, because a number without an age is not really a measurement.
Bots
Query protocols report bots separately from human players. Whether a directory adds them to the headline number is entirely a client-side decision, and both choices are defensible.
A 32-slot Team Fortress server running eighteen bots reads as 18/32 on a site that counts them and 0/32 on one that does not. Neither has made an error; they have answered "how many players" and "how many people" respectively, and those are different questions that share a word.
This is the single largest source of disagreement in games where bots are common, and it is invisible unless a site says which convention it uses.
Reserved slots move the maximum
Some server software subtracts administrative or donor slots from the maximum it advertises. Some does not. Some subtracts them only when they are occupied.
So the denominator moves as well as the numerator, and a server can genuinely report 30/30 to one query and 32/32 to another minutes later, depending on whether an admin connected in between. What "full" actually means is more complicated than the fraction suggests.
Some counts are simply invented
Plugins exist whose function is to report a number the server does not have. They work because nothing in any of these protocols verifies the claim.
A directory that only reads the headline number cannot detect this. One that also requests the player list can compare the two, but that costs a second round trip against every server on every sweep, which is why most do not.
What does eventually reveal it is time. Inflated counts tend to be too smooth, too flat, or to lack the overnight trough that a real population in a real timezone cannot avoid. That is a pattern visible across weeks and invisible in any single reading — the reason shape matters more than height when judging a chart.
Different lists ask different servers
Occasionally two sites disagree because they are querying different machines.
A community running several servers under one brand may be listed once on one site and five times on another. A server that moved hosts may be listed at both the old and new addresses. A network behind a proxy answers on behalf of whichever backend a player would land on, so the number describes the front door rather than any single room.
The tell is that the disagreement is large and persistent rather than a few players and a few minutes.
Uptime figures are not comparable at all
Player counts at least measure the same thing badly. Uptime figures do not measure the same thing.
An uptime percentage is built from a site's own successful queries. A query that timed out looks identical to a server that was down, so a site whose sweep was rate-limited records downtime that never happened. Query rate limiting is the most common cause of a server showing lower uptime on one site than another, and it is a property of the measurement rather than the server.
There is also no standard window. Ninety-nine percent over seven days and ninety-nine percent over ninety days are very different claims presented in the same format.
What to do with the disagreement
For players: treat any single number as approximate and look for agreement in shape rather than value. If three sites all show the same daily rhythm at different heights, the rhythm is real. If one shows a flat line and two show a curve, the flat one is measuring something else.
For operators: a discrepancy across every site at once is yours to investigate; a discrepancy on one site is usually that site. If your count reads lower everywhere than you know it is, check whether bots are involved. If your uptime reads worse on one site, check rate limiting before anything else.
And if a site is showing you as offline while others show you fine, that is almost always query-side rather than a server fault — the direct-connect test settles it in thirty seconds.
Why nobody standardises this
It would require every game's query protocol to define bots, reserved slots and sampling identically, and to make the fields non-optional. They were designed over two decades by different companies for different games, and several are older than the idea of a third-party directory.
The realistic ask is not standardisation but disclosure: a site saying how often it sweeps, whether it counts bots, and over what window its uptime is calculated. That is enough to make two numbers comparable, and it is rarer than it should be.
The short version
Different sweep intervals, different bot conventions, different reserved-slot handling, occasional invented numbers, and uptime figures built from each site's own failed queries. None of it is dishonesty; almost all of it is an unspecified field in a twenty-year-old protocol.
Read the shape across time rather than the number in the moment, and prefer sources that tell you how they measured.
Published · 5 min read