Dashboard
The Dashboard is the built-in overview screen. It is role-aware: every signed-in user gets a personal Your activity panel with their own numbers, and administrators additionally get a server-wide Server overview with live operational data. The two halves come from separate, independently gated endpoints, so a regular user never receives any of the server-wide figures - the split is enforced on the server, not just hidden in the interface.
The same data is exposed to plugin themes as window.__GD__.dashboard, so a custom theme can render its own dashboard from the identical payloads instead of the built-in screen. See Themes.
- Where to find it
- Time window and layout
- Your activity (all users)
- Server overview (admin)
- The live feed is admin-only
- Who can see what
- API reference
The Dashboard is a destination in the main navigation and lives at /dashboard. It is open to every signed-in user. What you see there depends on your role:
- a regular user sees Your activity only, and
- an administrator sees Your activity followed by Server overview.
Any plugin dashboard cards contributed by installed plugins render underneath, in their own Plugins section.
A window selector at the top - 24h, 7d, 30d, or Custom (a start and end date, end inclusive) - re-scopes the time-based sections. Point-in-time sections (library totals, users, platforms, disk, security, antivirus) always show the current state and ignore the window.
Each section is collapsible, and that collapsed state is remembered in your browser. A Customize mode lets you drag the blocks into a different order and hide the ones you do not care about; your layout is saved per user, and a Reset control puts it back to the default.
Your activity is drawn entirely from your own records - it is scoped to the calling user on the server, so it only ever reflects what you did. It covers:
- Downloads - four stat cards for the selected window: games downloaded (distinct titles), the number of file downloads behind them, total transferred, and your average download speed.
- Download activity - a sparkline of your downloads over the window (hourly buckets for short spans, daily otherwise).
- Game saves - a summary of your ROM savestates and battery saves with your storage quota, the same saves surface described in ROMs & Emulation. You can export and import saves from here.
- Your game requests - your most recent Game Requests with their current status, plus a pending count.
The personal payload can also carry Continue playing and Recently played ROM strips (games you have a save for, and games you most recently launched). In the built-in themes those two strips are rendered on the Home page rather than on the Dashboard, since "jump back into a game" belongs there - but they remain part of the personal data a theme can request. Everything in this panel is keyed to your user id; there is no way to read another user's activity through it.
Server overview is the operational console for the whole instance. Every field in it is server-side gated to administrators - the /api/dashboard/admin endpoint re-checks your role and returns 403 for anyone who is not an admin, so none of these figures are ever computed for or sent to a non-admin, regardless of theme.
A Live transfers panel shows what the server is moving right now, in three parts:
- Downloads in progress - the server pulling content in: in-flight GOG download jobs and torrents, each with progress, size, speed, and ETA. See Downloads & Torrents and GOG Integration.
- Uploads - the server sending files out to users who are downloading, attributed by username, so you can see who is downloading what at this moment.
- Seeding - library files being seeded to torrent peers, with the current upload rate and peer count.
The panel updates in real time over a push feed (falling back to polling if the socket is unavailable) and stays out of the way when nothing is transferring.
A Server health panel shows host vitals read straight from the operating system: CPU usage, RAM used against total, uptime, load average, and core count. These drift constantly, so on a live instance they refresh on their own through the same admin feed without a page reload. On non-Linux hosts the fields degrade gracefully to blanks rather than failing.
- Overview cards - games total (broken down into GOG / Custom / ROM), library size on disk, user and admin counts, downloads and average throughput for the window, emails sent, and the most active user for the window.
- Recently added - a cover strip of the newest library games and ROMs, each clickable through to its detail page.
- Downloads and Email activity - sparklines over the selected window.
- Top downloaded - the most-downloaded library games for the window. Clicking a row opens a who downloaded this drill-down listing each user, how many times, and how much.
- Top ROM platforms - a ranked bar list of platforms by ROM count and size, each linking to that platform's emulation library.
- Security - failed logins in the window, the number of distinct IPs behind them, and the currently banned IPs with the time left on each ban. This is the brute-force picture described in Network & Security.
- Antivirus - the ClamAV status: whether upload and download scanning are on, whether the daemon is running, the signature database version and date, the count of quarantined files, and the most recent quarantine entries (filename, threat, and what triggered the scan). See Security.
- Disk space - free and total space for each real data volume, de-duplicated by mount so a split-disk install (games or ROMs on a separate disk) reports each volume once.
- Game requests - the full request review queue embedded inline, where an administrator can approve, reject, mark done, or delete each request. Status changes fire the usual webhook and email to the requester. See Game Requests.
The real-time queue and health updates are pushed over Socket.IO, and the feed is restricted to administrators at every step. A dashboard subscribes on mount and unsubscribes on unmount, so the server does no work at all while nobody is watching. When a client asks to subscribe, the server checks the socket's role and re-resolves the current role from the database before admitting it, refusing on any doubt - so a socket that was opened while its owner was still an admin cannot keep the feed after a demotion. Subscribers are also re-checked periodically, and anyone who is no longer an enabled admin is dropped from the feed without waiting for a reconnect. The one-shot GET /api/dashboard/queue read and the who-downloaded drill-down are gated the same way as the admin overview: non-admins get 403.
| Panel | User | Admin |
|---|---|---|
| Your activity (own downloads, saves, requests) | + | + |
| Server overview (library, users, throughput, top user, platforms) | + | |
| Live transfer queue and server-health feed | + | |
| Security, antivirus, disk | + | |
| Game-request review queue | + | |
| Who-downloaded drill-down | + |
Both dashboard endpoints require the library.read permission (every role has it); the admin overview, the live queue, and the drill-down additionally require the Admin role on the server. See Users & Permissions.
All routes are prefixed with /api/dashboard. The same calls are wrapped for theme plugins under window.__GD__.dashboard (me(), admin(), queue(), onQueue(), onHealth(), gameDownloaders()), so a custom theme renders its own dashboard from these payloads.
| Method + path | Purpose | Access |
|---|---|---|
GET /me |
The signed-in user's own stats. Optional days (1 / 7 / 30) or start/end, and a sections subset (downloads, continue_playing, recently_played, requests) to compute only what you will render |
Read |
GET /admin |
Server-wide operational overview (library, downloads, users, most active user, platforms, security, antivirus, email, disk). Same window params as /me
|
Admin |
GET /queue |
Live server-side transfer queue snapshot (downloads, uploads, seeding) | Admin |
GET /game/{id}/downloaders |
Which users downloaded a given library game, and how much | Admin |
Here Read is the library.read permission (every role) and Admin additionally requires the Admin role; the admin routes return 403 otherwise.
The live feed is delivered over Socket.IO rather than HTTP: an admin client emits dashboard:subscribe / dashboard:unsubscribe, and the server pushes dashboard:queue (the transfer snapshot) and a dashboard:health heartbeat while it is watched.
Example - the personal dashboard for the last 7 days, play strips only:
curl -H "Authorization: Bearer <token>" \
"https://your-host/api/dashboard/me?days=7§ions=continue_playing,recently_played"Next: Downloads & Torrents - Game Requests - Users & Permissions - Themes