Skip to content

Dashboard

DomeNinchen edited this page Oct 16, 2026 · 8 revisions

Dashboard

The dashboard is what you land on after logging in and picking a server. It's a read-only overview — nothing here changes your TeamSpeak server, it only reports on it — so every role, down to Viewer, can see it for the servers they're assigned.

What it shows

The dashboard is made of eight tiles, and every user can arrange them for themselves (see Arranging the tiles). Out of the box they are:

  • Online users against the server's slot limit, channels and uptime — the same figures serverinfo reports, refreshed every 10 seconds. The server's name, version and platform sit in the header above the tiles. Which clients count as online can be narrowed by an admin, see Who counts as online.
  • Ping — see what "ping" actually measures below; it's real network reachability, not the number TeamSpeak calls "ping".
  • Users, last 24 hours — how many users were on the server over the past day; see History over days and weeks.
  • Bandwidth — incoming and outgoing bytes per second, as a chart of the last 20 minutes.
  • Server capacity, and the bot flows of this server (that tile only appears when the server has any).

Admins also have an Embed widgets button in the header. It manages the embeddable widgets for other websites — a separate feature that has nothing to do with the dashboard's own tiles.

Arranging the tiles

Customise in the dashboard's header opens a customise mode that lists every tile, hidden ones included, at its own width. For each tile you can:

  • change its place — drag it by its handle (mouse or touch) or use the arrow buttons. It works from the keyboard too: focus the handle, press space or enter to pick the tile up, move it with the arrow keys, drop it with space or enter, or cancel with escape;
  • show or hide it with the eye button;
  • set its width to a third, two thirds or the whole row. On a narrow screen such as a phone every tile takes the whole width anyway, in the same order.

Nothing changes until you press Save; Cancel throws the changes away. Reset puts the built-in layout back into the customise mode, and saving that removes your own layout, so from then on you simply follow the default again.

The layout belongs to your user account, not to the browser: it is the same on every device you sign in with, it survives clearing the browser's data, and every user has their own. It is one layout for all servers, not one per server. Every role can arrange its own dashboard — it only decides which tiles that user sees and where, never what a role is allowed to see. A tile that a later version adds shows up at the end of a saved layout, visible, so it doesn't go unnoticed; hide it if you don't want it.

In the Lounge layout (see Themes and Appearance) the dashboard opens with a sentence that already says the online users, uptime, channels and ping, so the four tiles with those numbers are not shown there. The customise mode marks them with In the sentence and locks their show/hide button; in the Cockpit layout they behave as described above.

Who counts as online

By default the online-users number counts every connected client except ServerQuery logins. Admins can narrow that per virtual server with the Online count button in the dashboard's header:

  • server groups — clients in any of the ticked groups are not counted (handy for a bot or AFK group);
  • this manager's music bots — a switch that leaves them out without needing a group for them.

The choice applies to the Online users tile and the Lounge sentence, for every user, on that virtual server. Server capacity keeps counting every connected client, because they occupy a slot either way, and the history is not filtered. The public widgets have a separate setting of their own.

The 20-minute history

The bandwidth chart and the small ping graph always show the last 20 minutes the moment you open the page — they don't start empty and fill in while you watch.

That's because the backend measures every running virtual server continuously, on its own, from the moment it starts — whether or not anyone has a dashboard open. It takes a sample every 30 seconds, re-checks every couple of minutes which virtual servers are actually online (so one you start later is picked up without restarting the backend), and stores the samples in its database. Because they're in the database and not just in memory, the history is still there right after a backend restart or a deployment, instead of being wiped every time the container restarts.

The window is exactly 20 minutes: older samples are pruned as new ones arrive, so this never grows into a long-term archive. At a 30-second cadence that's about 40 points per virtual server. If you want a finer or longer graph, the sampling interval and retention window are the two knobs, in the backend's bandwidth-sampler.ts. For the number of users, the bandwidth and the ping over days or weeks there is a separate long-term view, described next.

History over days and weeks

The dashboard's bandwidth and ping charts only look 20 minutes back. For anything longer, the backend keeps three things per virtual server: the number of users, the bandwidth and the ping. The Users, last 24 hours tile on the dashboard shows the past day of the user count (every role that can see the server sees it; admins also get a More in History link); Statistics → History shows all three for a day up to a month (admins only, like the rest of the Statistics page), picked with the Users | Bandwidth | Ping buttons at the top (your last choice is remembered in your browser). Both follow the server and virtual server you've selected at the top of the page, and the tile is drawn exactly like the tab's user chart — just compact, without legend or controls, and with the time zone you last chose on the tab.

  • Range: the last 24 hours, 3, 7, 14 or 31 days. The line is the average per time slot, with the peak as a faint area behind it and a dashed 24-hour average on top; hover to see the average, peak and minimum for a slot. Saturdays are shaded grey and Sundays red. A bar above the chart shows the current user count, the peak and when it happened (as "13 of 32 slots" when the slot limit at that moment is known), the average, availability, and when the last measurement was taken.
  • Slot limit: the Slot limit switch on the History tab (off by default, remembered in your browser) draws the server's slot limit as a dashed step line and lets the axis reach up to it, so you can see how close the users came. The limit is stored with every measurement, so a change you made shows up as a step. Measurements from before the limit was stored have none, and the switch is disabled, with an explanation, for a time range that has no limit at all.
  • Time zone: switch between your browser's own time zone and UTC. Day boundaries, weekends and the axis labels all follow the choice, and it's remembered in your browser.
  • Bandwidth: download and upload as two lines, each with its peak as a faint area behind it and a dashed 24-hour average, on an axis in the unit that suits the traffic (B/s, KB/s, MB/s). The average is exact: it is calculated from the difference of the server's own byte totals over the time it covers, so nothing between two measurements is missed. The peak is the highest single reading (one every 30 seconds) and therefore only a lower bound for the real peak. File transfers are counted separately by TeamSpeak and are not included. The bar above the chart shows the latest rate, the peak with its time, the average and the data volume of the selected range. While a virtual server is stopped the chart has no line, and the one data point in which a restarted virtual server's counters began again from zero is left empty rather than drawn wrong.
  • Ping: the mean with the lowest and highest value of each point, measured as a TCP connect to the connection's ping target (shown in the chart heading; see what "ping" actually measures). A ping that gets no answer is a timeout: it is marked in red along the top edge of the chart, counted in the tooltip and in a Timeouts figure, and never averaged in as 0 ms.
  • A gap is never drawn as zero. While measuring, the backend records why it couldn't measure anything: red means the server could not be reached, hatched grey means that virtual server was stopped, and plain empty means nobody was measuring (the backend itself wasn't running, or recording was switched off). A server that answers but refuses the request (a revoked API key, say) is logged but not drawn as an outage. A real "nobody online" is a genuine 0 on the line. The bandwidth and ping charts use the same marks.
  • Who counts as a user: the same figure as on the Virtual Servers page, all connected clients minus the ServerQuery connections. Other bots, including this app's own music bots, count like any client; the online count setting does not apply to the history.
  • Recording and storage: the backend records from the moment it starts, once a minute by default, and keeps 32 days. (Bandwidth and ping are still measured every 30 seconds, as for the dashboard; the interval is how often they are folded into one data point.) Both are settings in the Recording card at the bottom of the History tab (every 30 seconds to 5 minutes; 7 to 365 days). A month at the defaults is about 9 MB per virtual server (user count, bandwidth and ping together). Shortening the retention deletes the older history straight away, after a confirmation. Every connection is recorded by default; to leave one out, switch off Record history when you edit it (Settings → your connection) — what was already recorded is kept.

The dashboard itself still shows only the last 20 minutes of bandwidth and ping; the longer view is on the History tab.

What "ping" actually measures

The ping value is real network reachability of your server's host — the backend opens a TCP connection to it and times how long that takes, showing timeout if it can't connect at all. This is deliberately not TeamSpeak's own virtualserver_total_ping, which is an average over the clients currently connected and reads as a meaningless 0 whenever nobody happens to be online.

By default it times a connection to the same host the manager already uses to reach the server. If that host is an internal or Docker-network address that doesn't represent what your users actually connect to, set a separate ping target on the server connection (Settings → your connection) — for example your server's public hostname — and the dashboard will measure reachability of that instead, without affecting any of the manager's own connections.

Worth knowing: because measurement runs continuously, the configured ping target is contacted every 30 seconds around the clock, even when no dashboard is open. That's a steady, tiny stream of connections you may notice in a firewall or connection log — it's the dashboard history being kept current, not something probing your server. The History tab's ping chart is made from these same measurements; it adds none.

Statistics vs. the Dashboard

There's a separate Statistics page, and it answers a different question. The Dashboard is about one virtual server — the one you've selected. Statistics is instance-wide: how many virtual servers are online out of the total, combined users and channels across all of them, the instance uptime, and current bandwidth for the whole instance. Use the Dashboard for day-to-day watching of a server, Statistics for the health of the whole TeamSpeak instance at once. Statistics also has the History tab, the long-term view of a server's user count, bandwidth and ping described above.


v0.8, last edited 16.10.2026

Getting started

Home
Getting Started
Install on Debian 13
Setup: same machine
Setup: elsewhere / rented
Users and Roles

Using the app

Dashboard
Virtual Servers and Instance
Channels
Clients
Client Database
Permissions
Server and Channel Groups
Moderation
Tokens and Passwords
Files
Icons
Bot Flows
Music Bots
Server Widgets
Server Maintenance
Server Logs
Query Console
Connection Journal
Themes and Appearance

Running it

Administration
Configuration
Deployment
Privacy and Hosting

When something is odd

Tips and Pitfalls
Troubleshooting

Contributing

Development

Repository · Changelog

Clone this wiki locally