Hyperping's server agent reports used and free space for every real mount point, with the device and filesystem type attached, and filters out pseudo-filesystems such as tmpfs, proc, and overlay layers before the data reaches the dashboard. On Windows, each drive letter is a mount. Of all the ways a server fails, a full disk is the most predictable, and the chart shows the slope well before it hits the top.
90% full on a 20 GB volume leaves 2 GB, which one chatty log file can fill in an afternoon. 90% on a 4 TB volume leaves 400 GB and needs no attention at all. Watch free bytes together with the rate at which they shrink, so the warning arrives with hours or days to act, not at the moment writes start failing.
Full disks fail in ways that look like unrelated bugs:
A filesystem can also run out of inodes (the entries for each file) while free space still looks fine, which is why "No space left on device" sometimes contradicts the graph. Millions of tiny files, such as session files or a mail queue, are the usual cause. df -i shows inode usage.
When the current fill rate would fill the disk within a few days, or when free space drops below what a day of normal growth needs. Both beat a fixed 90%.
df -h for each filesystem, du -sh /var/* | sort -h to find what's using it, and df -i for inodes. See how to monitor disk space.
A deleted file is still open by a process. Find it with lsof +L1 and restart that process to release the space.