Observe the system for 5 to 10 minutes while the issue is happening. Check whether one process keeps using CPU or memory, swap keeps growing, disk activity remains busy, and which mount point is actually filling up. Load average, used memory, or one temperature reading cannot identify the cause by themselves.
Check in this order
- 1
Confirm the symptom and trigger
Note whether the issue follows login, one app, a system or package update, a build, a virtual machine, or sync work, or also happens while idle. A temporary background task that finishes normally is not automatically a fault.
- 2
Find the process with sustained usage
Use CoreRobin, System Monitor, or top to inspect processes. A process matters more when it stays busy for several minutes while the slowdown continues. Quit through the app first, and do not stop a daemon or desktop-session component merely because its name is unfamiliar.
- 3
Check available memory and swap
Linux uses otherwise idle memory for file cache, so high used memory does not usually mean memory pressure. Focus on whether available memory remains low, swap keeps growing, and one process continuously expands.
- 4
Identify the mount point that is full
The root filesystem, /home, container data, and external disks may live on different filesystems. Check free space for each mount point, then scan the matching path. Do not mix another disk's capacity or directory totals into the system-disk result.
- 5
Reproduce after restart, then review recent changes
If the problem returns after restart, review recently updated packages, kernels, graphics drivers, desktop extensions, startup entries, and resident services. Disable or roll back one item at a time and keep a recovery path.
Interpret these readings together
It reflects runnable or waiting tasks over time and must be interpreted with CPU count, process states, and the slowdown you experience. A short rise can simply mean the system is finishing work.
Kernels, boards, and hardware drivers expose different thermal sources, and some devices expose none. CoreRobin shows unavailable when it has no trustworthy sensor instead of estimating a value.
The Linux kernel documents 1, 5, and 15 minute load averages in /proc/loadavg and defines MemAvailable as an estimate of memory available for starting applications without swapping. Linux kernel documentation
GNOME System Monitor likewise supports sorting processes by CPU or memory and interpreting them alongside resource trends. GNOME System Monitor guide
Clean by mount point and path
- First identify whether /, /home, container data, or another mount point is filling up.
- Review Downloads, old packages, logs, browser caches, virtual machines, container images, and Trash, but confirm they are no longer needed.
- Remove packages through the distribution's package manager; do not manually delete /usr, /var/lib, or unfamiliar system directories.
- In CoreRobin, scan the matching path and review permission gaps. Adding an item to the cleanup basket does not delete it; the app rescans and asks again before permanent deletion.
GNOME recommends checking free space by filesystem, then using Disk Usage Analyzer to locate directories; space is not fully released until Trash is emptied. GNOME storage guide
Linux is currently an early preview
The Linux packages pass automated build and launch checks, but combinations of distributions, desktop environments, permissions, and sensor drivers are broad, so hardware coverage remains limited. AppImage is the easiest trial path, while Deb targets Debian, Ubuntu, and related distributions. Include the distribution, kernel version, and hardware when reporting missing readings.