The observation path
A dashboard is the last step, not the system.
Vitalis starts with providers for CPU, GPU, memory, storage, drives, fans, and thermal sensors. A background poller gathers snapshots and history, view models shape the state for navigation, and the COSMIC application turns that into overview cards and drill-down views. The layers matter because a pretty card with a weak data boundary is still a weak monitor.
Hardware support has honest seams
NVIDIA monitoring uses NVML, while AMD support falls back to sysfs. Storage health depends on SMART tooling. Fans and extra thermal sensors depend on what the kernel exposes through hwmon. These are useful integrations, but they are not universal truths. Vitalis can show which provider supplied a reading and where a machine simply does not expose one.
One overview, several questions
The overview is for the first question: is something obviously wrong? Drill-down pages handle the next ones: which CPU core is hot, what is the GPU doing, which process is consuming memory, is a drive reporting trouble, and are Proton or Wine workloads part of the load? Keeping those paths together makes the dashboard useful during actual debugging rather than only during idle screenshots.
A health score is a model
Vitalis combines component scores into a composite health view and records alerts for thermal, memory, storage, and fan events. That score is a navigation aid, not a medical certificate for a computer. The underlying component readings and alerts remain available so a surprising result can be inspected instead of accepted as a magic number.
History turns a snapshot into a clue
A single reading tells you what happened now. The rolling ten-minute buffer gives a short window for seeing whether a temperature spike settled, whether memory pressure is persistent, or whether a fan event tracks a workload. Full snapshots can also be exported to JSON for diagnostics and comparison outside the dashboard.