The Crew Dashboard
A local, read-first server console that turns machine telemetry into a control-room display you can understand at a glance.
- 1-second readings
- read-only collector
- local controls
- 8 themes
The server's own display
The dashboard is the screen shown on the server itself. It refreshes from the running machine once every second and is designed to be readable from across the room.
Reference machine: Intel Core i5-7200U, Ubuntu 26.04.1 LTS, 1 TB WDC drive, Wi-Fi and laptop AC/battery power reporting.
Program
fbconsole 0.2.1
Read rate
Once every second
Collector rights
No administrator rights
Display model
Observe first; local actions deliberately limited
Three parts. Deliberately kept apart.
The screen looks like one application, but collection, serving and drawing are independent layers.
01 · Read — Collector
Reads the machine once a second and writes everything into a single readings file. It only reads, and runs as an account with no powers.
02 · Serve — Local web server
Serves the page, its readings and a handful of local buttons. It listens only to the machine itself, not to the network.
03 · Draw — Dashboard page
Knows nothing about the machine. It fetches the file the collector wrote and draws the current state.
Everything on it was read from the machine a second ago.
Atomic readings. The collector writes a temporary file first, then swaps it into place in one step, so the page never reads a half-written document.
Failure isolation. The collector cannot change the machine, so a display fault cannot become a server fault. The screen can go out of date; it is never the authority.
CPU, memory, root disk and temperature
- CPU — busy time from the difference between two readings one second apart, not a meaningless single snapshot.
- Memory — genuinely available memory, not just “free”. Linux deliberately fills spare RAM with cached files.
- Root disk — how full the main filesystem is. A full disk breaks services in confusing ways and never recovers by itself.
- CPU temperature — from the processor's own sensor, with a simple word: cool, warm or hot.
Load averages 1 · 5 · 15 min. Read them against the core count: on a four-core system, a load of four means every core is busy.
Capacity, drive health and the twelve-row service check
Storage
Only genuinely mounted filesystems are shown. LVM free is space that can be given to a filesystem later; swap is disk overflow for memory pressure; SMART is the drive’s own health verdict; last backup is read from the backup tool itself.
- SMART PASSED
- LVM growth space
- backup timestamp
Services
Each row is asked directly whether it is running. Green means yes, red means no, amber means present but not in the expected state.
SSH · Cockpit · networking · name resolution · timekeeping · unattended updates · thermal management · cron · disk monitoring · firewall · failed units · lid behaviour
Traffic, signal, sessions, updates and power
Download on the left, upload on the right, calculated from bytes moved between readings. Wi-Fi strength is in dBm: negative, and closer to zero is stronger.
excellent
good
usable
weak
Upload higher than download is normal for a machine serving pages to other devices.
What happened, and what “DEGRADED” actually means
The event strip filters ordinary chatter and keeps notable lines from the system log, plus the watcher’s heat and load notes. The rings show now; the event log shows the last few minutes.
DEGRADED — one comparison, nothing more.
If the number of failed system units is greater than zero, the badge says DEGRADED; otherwise ONLINE. It does not mean slow, hot or unhealthy.
Action: go to the failed-units row in Services, identify the unit, and decide whether it matters.
Keyboard-first, mouse-optional
| HUB | Open the searchable server knowledge pages |
| PANEL | Open the hosting panel |
| CREW | Open the crew pages |
| T | Change the theme across the machine |
| + / - | Speaker volume |
| 0 | Mute or restore sound |
| B | Speak the latest status brief aloud |
| M | Mirror another screen, or return |
| ? | Open the keyboard map |
Every dashboard panel is clickable and opens a fuller view of the same information.
System information with a character interface
Crew Chat presents Serra as a listening interface with clearly stated capabilities — read, measure and speak — and an ask-first rule for anything that changes the machine.
- temperature
- load
- disk
- services
- backup
- how are you
Design principle: personality can sit on top of telemetry, but the measurements underneath stay explicit, inspectable and separate.
The 10-second check
How to read the dashboard when you walk past it.
- 01 · ONLINE or DEGRADED — If DEGRADED, inspect failed units and decide whether it matters.
- 02 · Failed logins — The one number that rises because somebody else is doing something to your machine.
- 03 · Last backup — If it isn't recent, it outranks almost everything else on the screen.
- 04 · Temperature + event strip — The ring is now; the log shows whether heat or load has been climbing.
- 05 · Root disk — A full main disk causes confusing failures and never improves by itself.
A dashboard with narrow powers
Collector: read-only
Runs under an account with no administrator rights.
Privilege is individual
Only a few named readings get their own privileged command.
Local web server
The page server listens only to the machine itself.
Network view: read-only
What other devices see is served separately.
Local changes are limited
Volume, theme, spoken line and mirror target only.
Names are validated
Theme, crew and project names are checked against a written pattern.
Observe the machine clearly. Change only what the console was built to change.
Technical enough to trust, visual enough to understand, and modular enough to grow with the project.
← FB Server Dashboards
All four system catalogs
FB Panel →
Next · Catalog 02






