Tracking Player Counts and Peak Hours on Your CS 1.6 Server

You cannot grow a server you are not measuring. "It feels busy in the evening" is a guess; a graph of players by hour is a decision. Knowing your real peak hours tells you when to be online to seed, when to schedule restarts so they miss the crowd, and whether a change actually helped. CS 1.6 gives you everything you need to build this yourself with no special software. This covers reading the count live, logging it over time, and acting on it.

1. Read the count live

The server always knows its current population. From the console or over RCON:

status

The status output lists every connected player with their name, SteamID, ping and IP, and the header shows the player count and map. For a scriptable single number, the server responds to the standard A2S info query on its UDP port (default 27015) with the current and max player counts — the same data a banner reads. Either way you have the instantaneous count; the value is in recording it over time.

2. Log the count on a schedule

To see peaks you need a time series. The simplest reliable method is a cron job on the server host that samples the count every few minutes and appends it with a timestamp to a log file. Query the count with an A2S tool or parse it from an RCON status call, then append:

# /etc/cron.d/cs-playercount — sample every 5 minutes
*/5 * * * * csuser /home/cs/count.sh >> /home/cs/players.log 2>&1

Each line becomes timestamp count. After a week you have 2000 samples — enough to see the shape of every day. This is the same cron mechanism used for scheduled restarts; you are just reading state instead of changing it.

3. Turn the log into peak hours

Group the samples by hour of day and average them. The hours with the highest average count are your peak — that is when to seed the server yourself, when to run events, and the window a new player is most likely to find it populated. The hours near zero are when a restart or map-heavy maintenance costs you nothing. Look for the daily pattern (evenings almost always dominate) and the weekly one (weekends usually higher). A week of data makes both obvious without any fancy tooling — even eyeballing the log grouped by hour tells the story.

4. Use a tracker for history you did not log yourself

If you did not start logging early, a public server tracker that you registered your server on (the same one that draws your banner) keeps a player-count history and often a peak-hours chart for free, because it has been querying your server on a schedule anyway. It is coarser than your own log but requires zero setup and covers the past. Register the server and let it accumulate history in the background as a backstop to your own sampling.

5. Act on what the data shows

The whole point is decisions. Peak at 8–11pm local? Be online at 8 to seed, and never schedule an automatic restart inside that window. Weekend spike? Run your events Saturday night. Made a change — new mode, FastDL fix, a marketing push — and want to know if it worked? Compare the week before to the week after on the same hours. Without the log you are guessing; with it you can prove a change moved the count.

Common mistakes

• Count is always zero in the log — the query hit the wrong port or sv_lan 1 blocks it. Confirm A2S responds on 27015; see A2S no response.
• Cron job never runs — wrong user or a non-executable script. Check the cron log and that count.sh has execute permission.
• Peak looks random — too few samples or you mixed time zones. Sample for a full week and normalise to one local time zone.
• Bots inflate the count — if you run bots, they may be counted; filter them out or you will misread real demand.
• Restart lands in prime time — you scheduled it before you had the data. Move it into a trough once you know where the trough is.

Verification

Run status and confirm the header count matches the number of players you can see in-game right now — that proves your source of truth. Let the cron logger run for a full week, then group the log by hour and confirm the shape matches your gut (a clear evening hump). If the graph and your intuition disagree, trust the graph and adjust your seeding time and restart schedule to fit it. A server run on real peak-hour data fills faster than one run on hunches.