Use df -h to see how full the overall filesystem is, and du -sh to find out which directory or file is actually using the space. They answer different questions: df reports free and used space at the filesystem level; du walks a directory tree and totals up what's inside it. When a quota warning shows up, du is almost always the one you want, because it tells you where to go clean things up.
df: how full is the filesystem
Run df -h from an SSH session to list every mounted filesystem with size, used space, available space, and percent used. The -h flag prints sizes in human-readable units (K, M, G) instead of raw block counts.
df -h
On shared hosting you'll usually see your home directory mounted on a shared volume with other accounts, so the total size shown isn't your personal quota; it's the whole disk. That's why df is the wrong tool for "how much of my plan have I used." For that number, see checking your hosting resource usage for where disk and bandwidth usage against your actual plan limits show up. On a VPS, df -h is more directly useful since the filesystem you see is yours alone, root and all. If you're new to VPS and want the full picture of what's dedicated to you versus what we manage, see VPS overview: what's included and where to find it.
Reading the output
The columns are Filesystem, Size, Used, Avail, Use%, and Mounted on. Focus on the line whose mount point matches where your files live, usually / or a path containing /home. If Use% is climbing toward 100, something is filling the disk, and du is how you find out what.
du: what's actually taking up space
du walks a directory recursively and reports size. The two flags you'll use constantly are -s (summarize, one total instead of every subfolder) and -h (human-readable). Combined:
du -sh public_html
That gives you one number for the whole directory. To break it down and find the specific folder that's bloated, drop -s and add a depth limit so you're not flooded with thousands of lines:
du -h --max-depth=1 public_html
This lists every immediate subdirectory of public_html with its total size, so you can see at a glance whether it's wp-content/uploads, a log file, or an old backup archive eating the space. Repeat the command one level deeper inside whichever folder is largest until you find the actual culprit.
Sorting to find the biggest offenders fast
Piping through sort puts the largest directories at the bottom where you'll see them without scrolling:
du -h --max-depth=1 public_html | sort -h
sort -h understands human-readable suffixes (K, M, G) and sorts by actual size rather than alphabetically by the text. If you don't have GNU sort with -h support, drop the -h flag from du and sort the raw byte counts numerically instead with sort -n.
Finding large individual files
Sometimes the problem isn't a directory full of small files. It's one huge file: a database dump, a log that never rotated, an old .tar.gz backup someone forgot about. find combined with size filtering is faster than walking directories by hand:
find public_html -type f -size +100M -exec ls -lh {} \;
This lists every file over 100MB under public_html along with its size. Adjust the size threshold depending on what you're hunting for. Error logs and PHP session files are common repeat offenders on long-running sites that nobody's cleaned up.
Shared hosting versus VPS: what root buys you
On shared hosting, your SSH session is scoped to your own account. You can run du and find freely inside your home directory, but you won't be able to inspect other accounts on the box, and system-level directories outside your home are off limits. df -h will show the shared volume's overall usage, which isn't actionable for you directly. Lean on the portal's usage view (linked above) for your actual allotment instead.
On a VPS, you have root, so du and df apply to the entire disk, not just a home directory. That means you're also responsible for finding space hogs anywhere on the system: package caches, Docker layers, log rotation that isn't configured, /var/log growing unbounded. Running du -h --max-depth=1 / as root (expect it to take a while and to error on a few permission-restricted paths, which is normal) gives you the top-level breakdown of the whole filesystem.
Once you've freed space
After deleting or archiving large files, re-run df -h to confirm the used percentage actually dropped. On shared hosting, also check the portal's resource usage view since it may take a short moment to reflect the change. A common trap: deleting a file that a running process still has open doesn't free the space until that process closes or restarts, so if du says the space is gone but df still shows it used, that's usually why.
When to contact support
If du and df disagree by a large margin and a service restart doesn't resolve it, or you're on shared hosting and hitting quota limits you don't understand even after cleaning up, open a ticket from the portal (Support → New ticket) or use live chat. It's a real person on the other end, and they can check things from the server side that aren't visible from inside your account.