What a Server List Measures, and What It Refuses To

Every server list shows you a number. Almost none of them tell you where it came from.

That gap matters more than it sounds, because the number is doing the deciding. A player scanning forty listings is not reading descriptions, they are reading player counts, and using them as a proxy for whether a place is alive. If those numbers are supplied by the people being ranked by them, the whole list is an advertisement wearing a table's clothes.

So it is worth setting out exactly how the figures here are produced, and: more usefully, which questions they answer and which ones they cannot.

The numbers come from the server, not from the owner

Every player count, uptime figure and peak hour on this site comes from querying the server directly, over the protocol that game speaks.

That means a small packet sent to the address on the listing, and a reply read from it. Counter-Strike, Team Fortress and the rest of the Source and GoldSrc family answer the Valve query protocol. Minecraft answers its own server list ping. FiveM answers over HTTP. SA-MP has its own UDP format. In every case the question is asked of the machine itself, and the machine answers with what is true at that moment: how many players, what map, what the server calls itself.

Nothing here is scraped from another list, and no owner types a player count into a form. There is no field for it, deliberately. Claiming a listing gives you control of every word on the page and none of the numbers, which is the arrangement that makes the numbers worth reading.

Every fifteen minutes. That is the sweep interval. It is a compromise between two failure modes: query too rarely and a server that went down at noon still shows as healthy at six; query too often and a directory becomes a distributed denial of service against the servers it exists to promote.

What the readings are used for

Player count is the most recent successful reading. Not an average, not a projection — the number the server last reported.

Online or offline is whether the last query got an answer. A server that does not reply is not assumed to be up.

Response time is how long the reply took. Useful as a rough health signal, and much less useful as a latency figure than people expect; see below.

Uptime is the share of the last seven days' queries that got an answer. Seven days because that is how long the individual readings are kept; the figure and the data behind it cover the same window, so the number can always be checked against the readings that produced it.

Peak hours are built from those same readings, grouped by hour. This is the figure most worth an owner's attention and the one most owners never look at, because it is the only one that tells you when your community exists rather than how big it is.

The rule that matters most: no interpolation

If nobody polled a given hour, that hour has no reading. It is not estimated, averaged from its neighbours, or filled in.

This is the single most important line in how any of this works, and it is worth explaining why a gap is left visible rather than smoothed away.

A filled gap looks exactly like a real measurement. There is no visual difference between an hour that was measured and an hour that was inferred, so once you allow inference the reader can no longer tell which is which, and neither can we. Charts get prettier and less true at the same time. A missing hour on a graph is honest about a limitation; a plausible curve through it is a small invented fact that will be read as a real one.

The practical consequence is that some servers have patchier histories than others, and that is information rather than noise. A gap usually means the server was unreachable, which is the thing an uptime figure exists to reveal.

What these numbers cannot tell you

This is the part that gets left out, and it is where most misreadings come from.

Response time is not your ping. A query reply travels from the server to a datacentre in one specific place. Your ping is from the server to you. If you are on a different continent from where the measurement was taken, the number on the listing is not your number and never was. For what determines latency, ping and latency explained and why routing beats distance are both more useful than any figure on a listing page.

A player count is not a quality score. It is how many people are connected. It does not distinguish players from bots on games that fill slots with them, does not know whether those people are enjoying themselves, and does not know whether they are all one group who will leave together. What a player count really tells you is the longer version.

Uptime is not reliability in the way an owner means it. A server that answers queries flawlessly while lagging horribly scores perfectly. The query says the process is alive; it says nothing about tick rate, which is what actually determines whether the game feels right.

Seven days is not a track record. It is a week. A server can be excellent for a year and show a bad week; a server can be new and show a perfect one. The figure answers "is this working now", not "has this been here a while".

An empty server is not a dead one. Almost every community server is empty for most of the day, because its community lives in one timezone. The listing shows a moment; the peak-hours view shows the pattern. Telling a dying server from a quiet one is the whole skill, and the moment is the least useful part of it.

What is deliberately not published

There are numbers that could be produced and are not, because they would be misleading in a way no caveat fixes.

A single quality score. Compressing uptime, population, response time and age into one number out of ten is the most requested feature on any directory and the worst idea in the space. The weights would be invented, no reader could see them, and every server would optimise for the formula instead of for players. Four honest figures a reader can weigh themselves beat one dishonest figure that weighs for them.

Estimated total players over time. It would require exactly the interpolation ruled out above.

Anything about who is playing. The queries read what the protocol exposes about the server. Vote records store a hash of the voter, never a raw address, and there is no attempt to build a picture of individual players. A directory does not need to know who you are to tell you whether a server is up.

How to check a list that does not tell you

The useful thing about knowing one method in detail is that it gives you questions to ask of any other list. Four of them separate a directory that measures from a directory that publishes.

Does an owner type the player count in? If there is a field for it on the submission form, every number on that site is a claim rather than a reading. This is more common than you would expect, particularly on lists that grew out of forum threads.

Does the count change when the server empties? Open a listing at a busy hour and again at four in the morning. A number that does not move is not being measured. This takes two visits and catches most of it.

Is there any uptime history at all? A current status is cheap: one query when the page loads. History requires querying on a schedule for weeks and storing the result, which is real infrastructure. Lists without it are showing you a moment and calling it a record.

Are gaps visible? A chart with no holes in it, on a service with hundreds of thousands of servers, is a chart that has been filled in. Some of those hours were not measured. The honest version has gaps, and looks worse for it.

None of this makes a list without these things useless. It makes it a directory rather than a measurement, and those are different tools — a directory is still the fastest way to discover that a server exists. The mistake is reading a claimed number as a measured one, which is exactly what the presentation invites.

What makes a server listing trustworthy applies the same scepticism one level down, to the individual listing rather than the list.

How to use this if you run a server

Three practical consequences.

You cannot improve a number by editing it, so improve the thing. The only route to a better uptime figure is a server that stays up, which means monitoring and knowing before your players do.

Check peak hours before you make decisions based on population. Owners routinely conclude a server is dying because they looked at it at the wrong time of day for several days running. The hourly shape on your stats page is the corrective, and it is frequently a surprise, a lot of servers turn out to have their real peak two or three hours from where the owner assumed.

A gap in the history is a real event. If your uptime shows an unexplained hole, something happened. It is worth finding out what, because the players who tried to connect during it did not get an explanation either.

How to use this if you are choosing a server

Read the shape, not the snapshot. Uptime over seven days and the hourly pattern together tell you far more than the current count, which is a single moment that happens to be now.

Then check the things no measurement covers: whether the description matches what you want, whether the rules read like they were written by someone who has run a community, and whether the Discord has recent messages in it. The numbers narrow the field to servers that are running. Everything after that is a judgement, and it should be.

The full method; cadence, arithmetic and limits, is set out on the methodology page. It is worth reading once, if only as a standard to hold other lists to.