Reading Your Server's Stats: Uptime, Peak Hours and Retention

Most server owners check one number. They look at the player count, feel briefly good or briefly bad about it, and close the tab. Six months later they still cannot say what time their server is busiest, whether the last update helped, or why the population dropped in March.

The player count is the least informative figure available, because it is a single moment and moments are noisy. Everything useful is in the shape, how the day rises and falls, how the week compares to the last one, where the gaps are. That is what a stats page is for, and reading it properly takes about five minutes a week.

Uptime: the number that is yours

Uptime is the share of scheduled queries over the last seven days that got an answer. Every fifteen minutes the server is asked whether it is there; uptime is how often it said yes.

It is the only figure on the page that is completely within your control. Player counts move with the season, the game's own updates, what streamers are playing and whether it is raining. Uptime moves only when your server is unreachable.

99% is not as good as it looks. Over seven days, 1% is about an hour and forty minutes. If that hour landed at 3am nobody noticed. If it landed at 9pm on Saturday it was your peak, and every person who tried to connect during it got nothing and went somewhere else. The percentage does not distinguish between those, which is why the figure alone is not enough.

Look at where the gaps are, not just how many. One long outage and forty short ones produce a similar percentage and mean completely different things. Forty short ones is a server that is restarting or crash-looping, which players experience as constant interruption. One long one is an incident with a cause.

Compare against your peak hours. Downtime during your quiet hours is nearly free. Downtime during your peak is expensive out of proportion to its length. Scheduled restarts should be deliberately placed in the trough, and a surprising number of servers restart at a fixed time that was chosen once and never checked against when people play.

If gaps are appearing without your knowledge, that is a monitoring problem rather than a stats problem: monitoring uptime properly is about finding out before your players do rather than after.

Peak hours: the most useful chart on the page

Every community server has a shape to its day, and that shape is set by the timezone of the people who built it rather than by anything you decided.

This is the chart owners look at least and should look at first, because almost every decision you make about the server has a right and wrong time attached to it.

You are probably wrong about your own peak. Owners tend to assume the busiest hours are the hours they themselves play, which is a sampling problem: you see a full server because you are there, and you are there at the same time every day. Measured, the real peak is frequently one to three hours from where the owner assumed, and sometimes it is a different day of the week entirely.

Everything schedulable should be scheduled against this. Restarts and maintenance go in the trough. Events go at the peak. Announcements go just before the peak, so they are seen by people arriving rather than by people leaving. Moderation coverage, if you have staff — should be thickest where the chart is highest, which sounds obvious and is routinely not done.

A second, smaller peak usually means a second timezone. If your chart has a main hump and a smaller one eight hours away, you have a group of players on the other side of the world. That is a real community with real needs, and it is invisible in the player count. It may be worth a dedicated event at their hour, and it is worth knowing before you conclude that "nobody plays in the morning".

A flattening chart is a warning. A healthy server has a pronounced peak, because communities gather. A chart that flattens over several weeks; the same low number all day, usually means the regulars have gone and what is left is passing traffic. Population can look stable while this happens, which is exactly why the shape matters more than the total.

Player count over time: read weeks, not days

The daily number is noise. A quiet Tuesday means nothing. What means something is this week against last week, and this month against last month.

Three weeks is the minimum honest trend. Two points is a line through anything. Owners routinely panic at a bad week and rewrite the ruleset in response to weather.

Look for the step, not the slope. Gradual decline is normal and mostly seasonal. A step: a level that drops and stays down — has a cause, and the cause has a date. Match the date against your own changes, the game's updates, and your uptime history. Most unexplained losses turn out to be one of three things: an outage during peak, a ruleset change that annoyed the regulars, or a game update that broke something quietly. A Valve update breaking community servers is the classic version of the third, and it is easy to miss because the server appears to be running perfectly.

Concurrent peak is more useful than average. The average is dragged down by the twenty hours nobody plays. The highest simultaneous count tells you how big the community is, and it is the number to watch when deciding whether you need more slots, or, occasionally, whether you should be running a second server.

Response time: less useful than it looks

Response time is how long the query took to come back from where the measurement was made. It is a rough health signal and it is not your players' ping.

What it is good for: noticing a change. A response time that has doubled since last month usually means something; an overloaded box, a network problem at the host, a neighbour on shared hardware.

What it is not good for: telling you what your players experience. Their latency depends on where they are and how the route between them and you happens to be built, which is a separate subject, routing, not distance, decides ping and ping and latency explained both cover why the intuitive model is wrong.

It says nothing about how the game feels. A server can answer queries in eight milliseconds and play terribly, because the query is answered by a networking thread and the game is simulated by a different one. Tick rate is the figure that governs feel, and no query can see it.

Gaps mean something

If an hour has no reading, it is left empty rather than filled in. That is deliberate — how these numbers are produced explains why inventing a plausible value is worse than showing a hole.

For an owner, a gap is a fact worth chasing. It means the server did not answer, which means players trying to connect at that moment also got nothing. Repeated gaps in the same hour every day are usually a scheduled restart taking longer than you think it does.

What none of it tells you

Whether people are enjoying themselves. Twenty players who are bored and twenty who are having the time of their lives are the same number. Retention is the closest proxy: people who come back had a good time, but the causes live in your Discord and your chat logs, not on a chart.

Whether your moderation is working. A server can look healthy for weeks while a small group makes it unpleasant for everyone else, and the population drop arrives long after the cause. Handling toxic players and moderating a community are the work; the chart only ever shows the consequence, late.

Who left, or why. Aggregate numbers cannot tell you that your six most active regulars stopped playing. That shows up as a small dip and it is the most important thing that can happen to a small server. You find it by noticing people, not by reading charts.

A five-minute weekly habit

Worth doing on the same day each week, because comparison is the whole point.

1. Uptime, and where the gaps were. Anything during peak needs a cause.
2. Peak-hour shape against last week. Flattening matters more than lowering.
3. Concurrent peak, this week against last. One number, one comparison.
4. Anything that changed on your side; a plugin, a rule, a map rotation — noted against the date, so next month's step has a candidate.

That is it. Five minutes, and it catches most of what a quarterly panic would have discovered too late.

Your own figures are on the stats pages, and it is worth looking at the game-wide view alongside your own: a decline that is happening to the entire game is a different problem from a decline that is happening to you, and the two are indistinguishable if you only ever look at yourself. If you have not listed yet, none of this exists for you, listing the server is where the measurement starts, and the history begins accruing the day it is approved.