System health and storage
Interpret Finetic CPU, memory, cache, database, service, storage and playback health without mistaking load-equivalent values for percentages.
Reading health correctly#
System Health combines process, database, cache, storage and playback signals. Every degraded card should explain the failing check, last observation and likely scope.
CPU#
CPU percentage measures recent process demand. Load average represents runnable or waiting work and can exceed the number of cores. 5.76 / 4 cores therefore means more work was queued than four cores could immediately execute; it is not the same measurement as 100% CPU.
Memory#
Memory shows Finetic process usage and host capacity. Linux also uses free RAM as filesystem cache, so low “free” memory alone is not proof of pressure. Repeated swapping, OOM termination or growing process retention is actionable.
Cache and temporary space#
The media cache holds replaceable HLS, subtitle and artwork assets. The card shows location, usage, quota and free space. One active remux can temporarily generate substantial data near source bitrate; pruning must preserve assets used by active sessions.
Database#
Database health covers connectivity, pool demand, schema readiness and storage. PostgreSQL is operational state, not disposable cache. Use verified Finetic backups before maintenance.
Service details#
Detail modals show the evidence behind a card: last check, recent samples, active processes or connections, and safe actions. Raw secrets and unrestricted environment values are never displayed.
When health is degraded#
Open the affected card before restarting. Determine whether the cause is persistent, such as a missing mount, or transient, such as a short transcode peak. Restarting can erase in-memory evidence without correcting the host constraint.