Server metrics

The share of total CPU time currently in use across the server. A low value usually means the machine has headroom.

How to read it: 4.2% is healthy for most idle or lightly loaded VPS hosts. Sustained 80% to 100% usually means the box is close to saturation.

Watch for: CPU usage alone does not tell you whether requests are slow. Check it alongside load average, memory pressure, and app health.

How many execution cores the server can schedule work onto.

How to read it: More cores means the server can handle more parallel work. Load average makes more sense when compared to this number.

Watch for: A load of 1 on a 1-core VPS is very different from a load of 1 on a 4-core VPS.

The average number of runnable or waiting tasks over the last 1, 5, and 15 minutes.

How to read it: Compare the first number to the CPU core count. On a 4-core server, a load of 1.07 is light. On a 1-core server, it means the machine is busier.

Watch for: Rising 1-minute load with lower 15-minute load usually means a recent spike. High load with low CPU can point to disk or network wait.

How much RAM is currently in use compared with the total available to the VPS.

How to read it: Consistently high memory use is not always bad, but sudden jumps or near-full usage can lead to swapping and slower response times.

Watch for: Watch for a combination of high memory use, degraded health checks, and restarts.

How much persistent storage is in use on the root filesystem.

How to read it: Leaving healthy free space matters for logs, images, package updates, and database growth.

Watch for: Disk problems often show up slowly. Clean old images, logs, backups, and failed build artifacts before the disk is nearly full.

How many filesystem entries are used. Files, directories, and symlinks all consume inodes.

How to read it: You can run out of inodes even when there is still free disk space left.

Watch for: Huge numbers of small files, caches, temp builds, or logs can cause inode pressure.

How long the server has been running since the last reboot.

How to read it: Long uptime can be a good stability signal, but only if updates and maintenance are still being done thoughtfully.

Watch for: Very low uptime after unexpected deploy or health failures can indicate crashes, forced reboots, or provider issues.

How many Docker containers are currently up, plus how many have stopped and remained exited.

How to read it: Running containers tell you what is active now. Exited containers can indicate failed jobs, stale workloads, or previous broken deploys.

Watch for: A growing exited count is a prompt to inspect logs and prune abandoned containers when appropriate.