The Disk Usage screen answers a question that several other errors ask badly. When an account is full, the failures it produces mention mail, uploads and databases, and none of them mention disk. This is where you find out.
Why it matters more than the number suggests
A full account cannot write anything. Incoming mail is rejected, uploads fail, database writes are refused and sessions break, all at the same moment and all with their own unrelated-sounding error messages.
That is why several faults reported together is so often one cause. Before investigating any of them individually, look here.
What the screen shows
It walks the account's directories and reports the size of each, largest first, with the ability to drill into any of them. Unlike the quota figure in the sidebar, which is a single number, this tells you where the space went.
The distinction is the whole point: knowing an account is at 94 percent is not actionable, and knowing that one mailbox holds nine gigabytes is.
The four places it usually is
Mail. The most common answer by a wide margin. Mail is stored one file per message, and the folders people forget are Sent, which is often larger than the inbox, Trash, which still occupies space after deletion, and Junk, which fills automatically and is rarely emptied. A single mailbox with an old POP client set to leave a copy on the server can outgrow the website by an order of magnitude.
Backups left in the home directory. A backup taken through the panel and never downloaded stays on the account, counting against the quota it was meant to protect. Three of them is not unusual.
Logs and caches. Application caches, session files and error logs that nobody prunes. An error log growing at a megabyte an hour because of a repeating warning is a quiet way to lose a lot of space.
The media library. On WordPress, every uploaded image is stored alongside several generated sizes, so an oversized original multiplies. There is more on that in managing a large WordPress media library.
The second disk limit nobody watches
A file system tracks two separate quantities: the bytes available and the number of files it can hold. Every file consumes one of those slots however small it is.
That means an account can be unable to write while showing plenty of free space, because it has run out of file slots rather than bytes. Millions of tiny session or cache files do it, and mail does it too, since every message is a file.
The error produced says the disk is full, because that is the only message the system has. If the usage screen shows space free and writes are still failing, this is why, and it is covered in understanding inodes and running out of them.
Reading it without being misled
Two things make the numbers look wrong.
The figure can be cached. Panels recalculate usage on a schedule rather than on every page load, so a large deletion may not show for a while. If the number has not moved after clearing several gigabytes, that is usually why.
Deleting a file an application still has open does not free the space. Removing the name leaves the data in place until the process releases it. Truncating the file or restarting the service returns the space immediately.
What to do once you know
If it is mail, the answer is per-mailbox quotas rather than a one-off cleanup, because a mailbox that filled once will fill again. A quota on each address means one address can no longer take the whole account down with it.
If it is backups, download them and delete the copies on the server. A backup stored on the same account survives an accidental deletion and nothing else, so it is doing very little for the space it occupies.
If it is logs or caches, find what is writing them. A log growing quickly is reporting something, and the something is usually worth fixing on its own account.
If it is genuine growth, the plan needs to change, and it is much better to have that conversation from a usage graph than from an outage.
What the number does not include
Two things sit outside the figure people expect to see, and both surprise somebody eventually.
Databases are counted separately on many plans. A database growing steadily does not move the file usage figure at all, so an account can appear comfortable while the part that is actually filling is invisible on this screen. If the usage looks fine and writes are still failing, check the database size on its own.
Files owned by another process may not be traversed. The scan reads what the account can read. Anything the account cannot enter is reported as nothing rather than as an error, which is rare and worth knowing about when the totals do not add up.
Explaining it to somebody whose site just stopped
The conversation is easier if the cause is named plainly. The account ran out of space, that is why mail bounced and the form stopped working, and here is the single folder that used most of it.
That framing matters because the alternative is a list of symptoms with no cause, which reads as a hosting problem rather than as a full mailbox. One of those is fixed in five minutes and the other becomes a support thread.
Checking it before anybody complains
This screen is worth opening on a schedule rather than during an incident. Disk fills gradually and visibly, which makes it the one resource problem that can always be seen coming.
For a reseller the same applies across accounts at once, from managing disk quotas and bandwidth in WHM. Five minutes there each month prevents the specific incident where a client reports three unrelated faults, all of which turn out to be the same full account.
