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.

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.

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.

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 diagnostics section allows you to generate a comprehensive diagnostic bundle that captures system state, logs, and configuration information. This bundle is useful when troubleshooting issues with the QuickBox support team.

Click Generate Diagnostics to create the bundle, which can then be downloaded as a file.

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