System Monitoring

The System Dashboard is your real-time telemetry center for monitoring server health. It provides live metrics, historical charts, hardware inventory, diagnostic tools, and automated alert rules — all in a wide-format layout designed for at-a-glance server awareness.

Key features

Overview metric strip

At the top of the System Dashboard, a row of KPI tiles gives you an instant snapshot of server health:

These tiles update in real time. A status indicator in the page header shows whether telemetry streaming is active.

Jump to a section

The System Dashboard is a long, wide-format page, so you can jump straight to any section instead of scrolling. Two paths reach the same place:

• Quick Navigation — expand Dashboard > System Dashboard in the sidebar to list every section as a child link.
• Search palette — press Ctrl+K (or Cmd+K on macOS) and search for a section by name, such as Service Health, Hardware Health, or Diagnostics.

Selecting either a Quick Navigation child or a search result scrolls to the section and briefly highlights it. The default child is Overview, which returns you to the top of the page — the header and the metric strip — and is also where System Dashboard lands you. As you scroll, the highlighted child follows the section you are currently viewing, in both the sidebar and the mobile menu. Sections that depend on a feature (Inter-Instance Transfers, Streaming Maintenance) or on hardware state (Software RAID, Fail2Ban Protection) appear only when that feature or state is present.

Bandwidth history

The bandwidth history section occupies the largest area of the System Dashboard. It displays time-series charts showing network throughput for your selected interface, powered by vnStat.

Key capabilities:

• Time range selection — Choose from predefined ranges or use the timeseries player controls to scrub through historical data
• Multiple interfaces — If your server has more than one network interface, select which one to chart from the command bar
• Chart interaction — Hover over data points to see exact values. The chart updates in real time when viewing the current time window

The health sidebar next to the bandwidth chart shows a compact summary of CPU, memory, and storage health with status badges.

Network topology auto-heal

vnStat keeps its tracked interface list in sync with your server automatically. When a bond, bridge, team, or VLAN-aggregate interface appears or disappears - for example, after you bond two NICs or remove a virtual bridge - vnStat re-registers the new topology on its own. You no longer need to manually drop old interfaces and add the bond before bandwidth charts start working.

CPU and memory panels

Below the bandwidth chart, dedicated CPU and memory panels display:

• Real-time utilization — Live-updating charts showing current CPU and memory usage
• Historical data — Time-series charts with the same range controls as the bandwidth section
• Per-core breakdown — CPU charts show individual core utilization when expanded
• Thermal data — CPU temperature readings when hardware sensors are available

Telemetry History Store

The System Dashboard keeps a durable, on-box history of your server’s metrics so the CPU, memory, network, and disk history charts stay gap-free — they survive service restarts, dashboard deploys, a full reinstall of the main database, and Redis being absent. The Telemetry History Store panel sits below the live metric charts and gives you a per-metric view of exactly how much history is preserved.

Summary row

At the top of the panel, a summary row shows the total rows stored, the on-disk size of the store, the number of retention tiers, and a live health status — Active or Idle.

Metrics that are persisted

Nine system metrics are recorded into the store:

• CPU, memory, network, disk usage, disk I/O, load average, swap, GPU, and temperature.

Each metric is written by a read-only observer of the live samplers, so a storage hiccup can never interrupt live sampling, the live stream, or a dashboard request.

Tiered retention

Every sample is downsampled on write into four resolution tiers at once — a running average lives in the database, so the rollups survive a restart. Charts automatically pick the tier that fits the range you ask for, so a multi-year view reads the 1-day tier instead of millions of raw rows.

Per-metric cards

Below the summary, a grid of cards — one per metric — shows how the history for that metric is doing:

• Coverage ring — how much history is preserved toward the next retention ceiling, colored by freshness.
• Health pill — Live, Idle, Delayed, or Stale.
• Total span — the full time range of history held for the metric.
• Row count — how many samples are stored.
• What it feeds — which dashboard chart or feature the metric powers.
• Per-resolution table — Raw / 1 min / 1 hour / 1 day, each with its retention, row count, and newest sample.

Each metric feeds a specific part of the dashboard:

GPU and temperature cards

Two cards behave differently from the rest:

• GPU is activity-bound. GPU metrics are sampled while the Streaming Dashboard is open or a hardware-accelerated stream is running — a playback session that transcodes on the GPU — so GPU history is naturally intermittent. When GPU samples age out, the card shows a neutral Idle rather than a red “Stale.”
• Temperature is sensor-conditional. A temperature card appears only if the host reports a CPU temperature. Sensorless VMs and containers simply have no temperature card.

The seven universal metrics (CPU, memory, network, disk, disk I/O, load average, swap) always have a card. A single conditional fourth card completes a symmetric grid — GPU is preferred, otherwise temperature, and never both. A host with neither shows a clean three-card second row. The unpicked series is still stored, just not shown as a card.

Clearing history

A Clear history button permanently wipes the stored history. It is confirm-gated, so an accidental click never discards your history. Live charts keep updating after a clear; historical ranges are empty until data re-accumulates.

System inventory

The system inventory panel displays your server’s hardware and software details:

• Hardware — CPU model, core/thread count, total memory, disk capacity
• Operating system — Distribution, kernel version, hostname
• Service uptime — How long the server has been running since last reboot
• Mount points — Configured storage mount points with usage breakdown

Software RAID monitoring

On servers with Linux software RAID (mdadm) arrays, the System Dashboard displays a dedicated RAID panel with live array status, member disk health, and rebuild progress. The panel appears automatically when RAID arrays are detected — no configuration is required. On servers without software RAID, the panel is hidden entirely with zero overhead.

Array overview

Each detected array shows key identification and status information:

Drive SMART health

For each member disk in an array, the panel collects S.M.A.R.T. data to assess drive health. SMART data refreshes every 5 minutes (independently of the 15-second array status updates) because the underlying smartctl probes are resource-intensive. Both SATA/SAS and NVMe drives are supported.

Health indicators

The RAID panel uses a color-coded health system derived from array state, SMART data, and mismatch counts:

Rebuild progress

When an array is rebuilding, resyncing, reshaping, or running a consistency check, the panel displays a progress indicator with:

• Percentage complete — how far the operation has progressed (0–100%)
• Speed — current throughput of the rebuild operation (e.g., 185000K/sec)
• Estimated time remaining — projected finish time based on current speed

The array state changes to “rebuilding” and the health status is set to “critical” for the duration of the operation, ensuring visibility.

Hardware health

Below the RAID panel, a full-width Hardware Health panel gives you a one-glance read of the physical box — platform identity, CPU health, and memory health. Every server has a CPU, so this panel is always present once the first sample arrives. It is read-only and needs no packages installed; the labels and thresholds it shows are read straight from the kernel’s own sysfs and /proc interfaces.

Status and findings

A colored status pill sits next to the panel title, and any active findings appear in a strip directly beneath it:

Measurement-gap chips

Rather than showing fake green readings, the panel is honest about what a given box does not expose. Neutral chips describe each measurement gap:

Managing notices

Every entry the panel raises - each finding in the strip beneath the status pill and each measurement-gap chip - is a notice an admin can manage. Tick one or several, then use the row action or the bulk bar:

Hidden notices no longer count toward the Hardware Health status, so a panel whose only remaining notices are hidden reads Healthy. The full-detail diagnostics export still includes them, so support always sees the complete picture. Where a notice has a real reset, that reset is offered alongside the hide and dismiss actions - kernel dumps clear with Clear dump history, and dismissing the thermal-throttle notice baselines the counters so it starts fresh.

Platform column

Non-identifying SMBIOS fields describing the machine itself:

The Product row shows the product name reported by firmware, which some hosted bare-metal servers leave blank. When firmware reports no name, an admin can select the pencil to add a product label of up to 64 characters, such as the hosting product code; when both a label and a firmware name are present, the label is shown and the firmware value appears on hover.

CPU column

Kernel dump history

The kernel-dump count is read from the server’s kernel logs, so it reflects real history rather than only the current uptime. A caption under the histogram records where the numbers come from and how fresh they are — for example, from kern.log · oldest 2026-08-02 · newest 2026-09-02 · scanned 12s ago. Because the kernel logs rotate weekly, the history covers roughly the last five weeks.

Under that caption, a since-boot line tells you whether any dumps have landed since the machine last started. It reads No dumps since the current boot (2026-09-02) in green when the box has been clean since boot, or 3 since the current boot (2026-09-02) in amber when new dumps have arrived. The dominant-faulting-CPU finding carries the same signal at the end of its message, ending ; none since the current boot (2026-09-02) or ; 3 since the current boot.

The panel re-scans the kernel logs every 5 minutes. To refresh the count immediately, select Rescan kernel logs.

Power profile

The CPU column includes a Power profile row that tells you, in plain language, how the processor’s clocks are governed right now, together with the Turbo boost state. It reads as Performance, Balanced, or Power saver — or Custom when the running settings don’t match a named profile. The row itself shows only the profile and Turbo state; the raw kernel governor and energy-preference values appear on the control’s “Now:” line (for example, “Balanced (powersave · balance_performance)”), so operators who know them can still see the underlying settings.

Where the profile is QuickBox’s to set, a Change button on the row opens the control. The control offers three profiles, a Turbo boost switch, and a “Now / At boot” strip that shows what is running now against what will load at boot.

Turbo boost lets cores briefly run above their base clock when there is thermal headroom. A profile that this CPU’s driver does not offer is shown disabled and labelled Not offered by this CPU’s driver rather than hidden.

Your choice is persisted by QuickBox, so it survives a reboot. When cpufrequtils is installed, QuickBox keeps its configuration in agreement so both apply the same setting at boot, and no package is installed to make any of this work.

Memory column

Writeback cleanup

The Writeback cleanup card sits at the bottom of the Hardware Health panel and is admin-only. It is the dashboard equivalent of the qb fix writeback CLI command - an admin can run the same check and fix from the browser instead of the terminal. It detects a kernel cgroup-writeback cleanup livelock, where two kernel worker threads peg a CPU while a dying control group’s cached inodes stop draining, and can release the unreferenced inodes so the drain finishes.

The card runs a read-only check automatically when the panel opens - it never polls, and never changes anything on its own. The circular refresh icon in the card header re-runs that check on demand.

A verdict badge next to the card title reports the outcome:

Below the badge the card lists the state behind the verdict:

The card also prints the check’s own one-line hint on what to do next.

System users

This section shows Linux user accounts currently connected to the server and their active sessions. Each entry displays the username, terminal, connection time, and source IP address.

Health cards

The health cards provide deeper analysis for three key resource areas:

• CPU Health — Load averages, governor settings, per-core utilization, and thermal status
• Memory Health — Detailed breakdown of used, cached, buffered, and available memory plus swap usage
• Storage Health — Per-mount usage, inode consumption, and growth trends

Each card includes a status indicator (healthy, warning, or critical) based on current utilization thresholds.

Quick actions

The quick actions section provides one-click access to common system operations:

Reboot and shutdown

These two power controls let an admin restart or fully power off the host directly from the dashboard:

Each control opens a confirmation dialog before anything happens. The reboot dialog offers a Reboot now option alongside scheduling controls (see Scheduling reboots below). Shutdown carries extra friction because it cannot be undone from the dashboard: you must type SHUTDOWN into the confirmation field before the Shut Down Server button activates. Shutdown is always immediate — there is no scheduling for power-off.

After you confirm a reboot-now or shutdown, the dashboard responds first and then the server reboots or powers off a few seconds later, so you receive a confirmation message before the connection drops.

Scheduling reboots

Administrators can schedule reboots for later instead of restarting immediately. Inside the reboot confirmation dialog, a timing selector offers three modes — Reboot now, One-time, and Recurring. The first restarts the host right away; the other two create a saved schedule that fires automatically at the time you choose. Scheduling is reboot-only — shutdown has no scheduling option.

To create a one-time schedule, choose One-time, set the date and time, and select Schedule Reboot. For a recurring schedule, choose Recurring, set how often (the Every value and Days or Weeks unit) and the At time of day, then select Schedule Reboot.

All existing reboot schedules are listed in the same dialog under Scheduled reboots, each showing when it next fires. Select the trash icon beside a schedule to cancel it — its next run is removed and it will no longer reboot the server.

Monitor rules

Monitor rules let you set up automated alerts when server resources cross defined thresholds. You can create rules for:

• CPU usage — Alert when CPU exceeds a percentage for a sustained period
• Memory usage — Alert when RAM usage crosses a threshold
• Disk usage — Alert when storage consumption reaches a warning level

Each rule can trigger configurable actions, such as sending a notification to admins.

Updates Available

The Updates Available panel is a collapsible widget that lists every package with a pending update in one searchable table. Collapsed, it summarizes the count - for example, 4 updates pending · checked 2 minutes ago, or No updates available. when everything is current. Expand it for the full table.

The table draws from two sources, shown in the Source column and selectable with the Source filter (All Source, QuickBox, APT):

Every column is sortable, and the search box (Search packages…) filters by package name. On a phone the Current column is hidden and the Available field shows the change as installed → available.

Both QuickBox rows carry an Open Updates link to the updates page, where either component can be updated, alongside the matching CLI command for reference - qb update quickbox for the CLI core and qb update dashboard for the Dashboard. See Updates & Changelog for the full update workflow.

Admins also get an Update APT Dependencies button on the panel. It applies to the APT package rows only - the QuickBox rows are updated from the updates page or the CLI, not by this button.

APT runner

The APT Runner is a slide-out panel for managing operating system package updates:

• Pending updates — View a list of available system package updates
• Apply updates — Run package updates with live output streaming
• Update history — Review previously applied updates

Diagnostics

The System Dashboard is the preferred, fastest way to gather diagnostics for a support thread — no terminal required. There are two levels, depending on how much detail support asks for.

Quick snapshot — “Copy diagnostics” (top right)

The command bar at the top right of the System Dashboard has a Copy diagnostics button. One click copies a readable live-telemetry snapshot — CPU, memory, disk, network throughput, the active time ranges, and vnStat status — to your clipboard. Paste it straight into your Discord support thread. This is all most first replies need.

Full report — the “Diagnostics” panel (bottom of the page)

Scroll to the bottom of the System Dashboard to the Diagnostics panel (“System information for troubleshooting”). It opens expanded on its Application section, and expands into collapsible sections — Application, System, Services, Audit, Network Interfaces, and Recent Errors — and flip the Advanced toggle for extended service and network detail.

Along the bottom of the panel are four export buttons that produce a redacted report, safe to paste into a public thread:

These standard exports mask host identity — they replace this server’s hostname, its public IPv4 and IPv6 addresses (a private IPv4 like 10.x or loopback ::1 stays), and adapters with custom names. That makes them safe to share publicly, but they still describe your machine (hardware, versions, timezone), so avoid posting them where you would not post those details.

Full detail bundle — for a DM when support asks

Next to the four export buttons is a Full detail menu. Its options — Copy to clipboard, Download .txt, Download .json, and Download bundle — produce the unredacted report, with your hostname and addresses left in so support can match the report to your exact server.

Use Full detail → Download bundle when support asks a follow-up question and needs the complete picture. Because it carries host identity, send it in a direct message to QuickBox support for an open case — do not post it in a public channel.

Streaming Maintenance

When WSDashboard is active, the System Dashboard includes a Streaming Maintenance panel directly below the RAID section. This panel gives admins a single place to trigger and monitor background maintenance tasks across all configured media servers — without leaving the system view.

What it shows

The panel renders one section per connected media server (Plex, Emby, and Jellyfin each appear separately when configured). Each section lists the maintenance tasks reported by that server, along with their current state, last-run time, and result status.

If a configured server returns no scheduled tasks, its section displays “No tasks reported” rather than being hidden entirely.

Task sources by server type

Emby and Jellyfin expose their maintenance operations through a standard Scheduled Tasks API. Plex uses a different subsystem called Butler — a set of named background jobs the Plex Media Server runs on its own schedule (library refreshes, database optimization, media analysis, bundle cleanup, and others). Butler task names and categories do not match Emby/Jellyfin task names, but the panel presents them in the same format.

On Plex, the panel also surfaces any active Activities — operations that are currently running rather than scheduled (for example, a library scan initiated from the Plex web interface). Active Activities appear alongside Butler tasks in the Plex section and can be cancelled if the activity supports cancellation.

Running and cancelling tasks

Click Run on any idle task to enqueue it immediately. The task state changes to running and a progress bar appears. Click Cancel on a running task to stop it. For Plex, cancellation routes to the appropriate endpoint depending on whether the task is a Butler task or an active Activity.

Live progress updates arrive through the dashboard’s server-sent events stream (activity.update events), so you see scan/refresh/optimize progress without refreshing the page.

Inter-Instance Transfers

When Inter-Instance Transfer is enabled, the System Dashboard includes a live cockpit for the transfers currently moving to and from this server. It is a monitoring surface — for the full send, approve, and pull workflow, see the Inter-Instance Transfer page.

The cockpit shows:

• Summary strip — the number of active transfers, aggregate speed, and bytes moved in flight.
• Sender → receiver node-map — a live map of this server and the peers it is exchanging data with.
• Per-transfer rows — one row per active transfer: the local user, the direction (sending or receiving), the peer, size and percent complete, file count, elapsed time, average speed, live speed, and status.
• A Transfers page button out to the full page, plus — for peers that have opted in — a deep-link straight to that peer’s own Transfers page.

CLI equivalents

Best practices

FAQ

Related pages