Discord Bot Statistics Panel: Server Count and Metrics

A Discord bot statistics panel lets you see, at a glance, how many servers your bot is in, how many users it serves and which commands run most often. These metrics are invaluable both for tracking your bot's growth and for understanding which features people actually use. In this article I walk through how to collect, store and display usage metrics with discord.js, starting with the most fundamental one: the server count.

Which metrics should you track?

Instead of collecting every possible number, focus on the ones that inform decisions. For most bots these core metrics are enough:

• Server (guild) count — the total number of servers your bot is in. The most direct sign of growth.
• Total user count — the approximate audience you reach (the sum of server member counts).
• Command usage — how many times each slash command has been run.
• Active servers — servers that ran at least one command in the last 24 hours.
• Shard health — once the bot grows, each shard's latency and uptime.

Mind privacy: never store sensitive data such as message content. Numbers are enough for statistics; the content is not needed.

Reading the server count in real time

The most basic metric, the server count, comes straight from client.guilds.cache in discord.js. You can read it when the bot is ready and update it whenever the bot joins or leaves a server:

const { Client, GatewayIntentBits, Events } = require('discord.js');

const client = new Client({ intents: [GatewayIntentBits.Guilds] });

client.once(Events.ClientReady, (c) => {
  const serverCount = c.guilds.cache.size;
  const userCount = c.guilds.cache.reduce(
    (acc, g) => acc + g.memberCount, 0
  );
  console.log(`${c.user.tag} in ${serverCount} servers, ~${userCount} users`);
});

client.on(Events.GuildCreate, (guild) => {
  console.log(`Joined: ${guild.name} (${guild.memberCount})`);
});

client.on(Events.GuildDelete, (guild) => {
  console.log(`Left: ${guild.name}`);
});

client.login(process.env.DISCORD_TOKEN);

The memberCount field gives a server's total member count without needing an extra intent or fetching the full member list, which makes it ideal and fast for estimating your user reach.

Recording command usage

To learn which commands are valuable, you need to write every invocation somewhere persistent. You can keep a simple counter in your slash command handler. In the example below we push each command call to a database:

client.on(Events.InteractionCreate, async (interaction) => {
  if (!interaction.isChatInputCommand()) return;

  // Run the command...
  const command = commands.get(interaction.commandName);
  if (command) await command.execute(interaction);

  // Record the metric (without blocking)
  recordUsage(interaction.commandName, interaction.guildId)
    .catch(console.error);
});

Writing the metric must not slow down the command's reply. That is why we hand it off to a separate function without await and catch the error. For storage, SQLite is great for small bots, while PostgreSQL or Redis (for fast counters) make sense as you grow.

Storing the data: a simple schema

A plain two-table layout is usually enough for statistics. One table for snapshots over time, one for command counters:

CREATE TABLE stat_snapshots (
  id          INTEGER PRIMARY KEY,
  server_count INTEGER NOT NULL,
  user_count   INTEGER NOT NULL,
  recorded_at  TEXT NOT NULL DEFAULT (datetime('now'))
);

CREATE TABLE command_usage (
  command   TEXT NOT NULL,
  guild_id  TEXT,
  used_at   TEXT NOT NULL DEFAULT (datetime('now'))
);

Adding a row to the snapshot table every hour or once a day lets you plot the server count over time. You can do this with a simple interval:

const ONE_HOUR = 60 * 60 * 1000;

setInterval(() => {
  const servers = client.guilds.cache.size;
  const users = client.guilds.cache.reduce(
    (a, g) => a + g.memberCount, 0
  );
  db.run(
    'INSERT INTO stat_snapshots (server_count, user_count) VALUES (?, ?)',
    [servers, users]
  );
}, ONE_HOUR);

Shipping the panel: a small API and UI

Once you collect the data, a tiny HTTP server is enough to show it in a panel. With Express you can expose an endpoint that returns JSON and render it as simple cards on the front end:

const express = require('express');
const app = express();

app.get('/api/stats', (req, res) => {
  res.json({
    servers: client.guilds.cache.size,
    users: client.guilds.cache.reduce((a, g) => a + g.memberCount, 0),
    uptime: Math.floor(client.uptime / 1000),
    ping: client.ws.ping,
  });
});

app.listen(3000);

On the front end you can fetch this endpoint every few seconds and update the numbers to give a live feel. For a historical chart, just feed the stat_snapshots data into a line-chart library such as Chart.js. If the panel is public, protect any write endpoints and expose only read-only statistics.

Counting totals on a sharded bot

When your bot grows and moves to sharding, each shard only sees its own servers. For an accurate total you have to aggregate across all shards. discord.js's ShardingManager makes this easy:

const total = await client.shard.fetchClientValues('guilds.cache.size');
const serverCount = total.reduce((acc, n) => acc + n, 0);

This call asks every shard and returns an array that you sum up. For computed values such as the user count you use broadcastEval. You don't need to set up sharding early, but designing your panel around aggregation from the start makes the future migration much smoother.

Frequently Asked Questions

Can I show the server count in the bot's status?

Yes. With client.user.setActivity you can display text like "in X servers". Update it on join/leave events or every few minutes; updating too often can hit rate limits.

Is the user count exact?

memberCount gives the total members a server reports, but the same person can be in several of your servers, so it is a "reach" estimate rather than a count of unique users. Counting unique users is far more costly and usually unnecessary.

Which database should I choose?

Up to a few hundred servers, SQLite is more than enough and needs zero setup. As you grow, move to PostgreSQL, and use Redis for very high-frequency counters.

Want a professional statistics panel for your bot? From server count to command analytics, I'll build the metrics pipeline and design the live panel. Get in touch and start running your bot with data.