Disk and bandwidth are the two limits every hosting account carries, and they fail in completely different ways. Disk failure is loud and immediate. Bandwidth failure is a bill or a suspension at the end of a month, by which time the cause is history.
Both are set per account in WHM, and both inherit from the package unless you override them.
Where the numbers come from
A package defines the defaults. An account created on that package receives them, and from that moment the account holds its own values.
This matters more than it sounds: changing a package does not change existing accounts. Raise the disk quota on your starter package and every existing starter client keeps their old figure.
To move existing accounts, either change each one, or re-apply the package to them, which resets everything else to package defaults too, including any exception you made deliberately.
Changing one account
In WHM, open Modify an Account, choose the account, and set the disk quota and monthly bandwidth.
Unlimited is an option for both. It is the right setting far less often than it is used.
An unlimited account cannot be measured, and it cannot warn you. When something goes wrong (a runaway log, a backup plugin writing hourly) you find out when the server's own disk fills, which affects every account on it rather than only that one.
Set a generous number instead of no number. The point is not to restrict the client; it is to have a ceiling that fails on one account rather than on the machine.
What actually counts
Both figures include more than people assume, and the surprises are consistent.
Disk counts files, databases and mail together. Mail is usually the one that grows unnoticed. A mailbox nobody reads with ten years in it. Log files are second.
Bandwidth counts every byte in and out: the website, FTP transfers, and mail. A client sending large attachments consumes bandwidth without ever touching their site.
So an account near its bandwidth limit with modest site traffic is usually mail or backups, and looking at visitor numbers to explain it leads nowhere.
What happens at the limit
The two are not comparable in severity, and it is worth knowing which you are dealing with.
Disk full. Everything stops at once. Incoming mail is rejected, uploads fail, database writes are refused, sessions break. None of the resulting errors mention disk, which is why several unrelated faults reported together is so often a full account.
Bandwidth exceeded. The site is suspended and visitors see a notice. Mail usually continues. It resets at the start of the next billing month, so it is recoverable by waiting, which is rarely acceptable to the client.
Make the warnings reach someone
cPanel emails quota warnings to the account's contact address, and the default is an address on the account itself.
A full account cannot receive mail. So the warning about the account being full fails to arrive because the account is full, at the exact moment it was needed.
Set contact addresses to something external. As a reseller, set yours to receive them too: hearing about a client's disk problem before they do is the difference between maintenance and an incident.
When quota figures look wrong
Occasionally an account shows usage that does not match reality, usually after a restore or a large deletion.
Quota data can drift out of step with the filesystem. WHM has a fix for it: rescan or repair quotas, which recalculates from disk rather than trusting the stored figure.
Run that before investigating a client's report of impossible usage. It resolves a good share of them.
Before raising a limit, find out why it was reached
Raising the number is the fast answer and often the wrong one.
Three causes account for most disk problems, and only one is real growth: backup plugins writing into the account and never cleaning up, log files with no rotation, and mail nobody has ever deleted.
All three come back. An account topped up without addressing them fills again on the same schedule, and the second conversation is harder than the first. Monitoring your hosting resources sets out what to show the client.
Bandwidth spikes are usually not customers
A sudden increase is worth reading before acting on.
Bot and crawler traffic consumes real bandwidth. So does an image of yours being embedded on someone else's busy page. Hotlink protection deals with that case, and whether it is worth acting on.
And check the direction. Heavy outbound traffic with no matching visitors can mean a compromised account being used to serve files. That is a security incident instead of a capacity problem, and raising the limit would simply fund it.
Reviewing the whole server
WHM lists every account with its usage against its limits. Read it monthly rather than when something breaks.
Two things to look for: accounts consistently near their ceiling, which is an upgrade conversation to have before it becomes an outage; and accounts using almost nothing, which is worth knowing when you are deciding what your packages should contain.
Also watch the total. Selling more disk than the server has is normal practice and works because nobody uses their full allocation, until several accounts do at once. Knowing your actual overcommitment is the difference between a considered risk and a surprise.
Find out what is consuming it before changing the number
Raising a limit without knowing why it was reached moves the same problem a month into the future.
du -sh /home/username/* 2>/dev/null | sort -h | tail -8 du -sh /home/username/mail 2>/dev/null find /home/username -xdev -size +100M -type f 2>/dev/null | head du -sh /home/username/.trash /home/username/tmp 2>/dev/null
Four things account for most of it: mail that was never deleted, backups the customer generated and left in place, log files, and a cache directory that grows without bound.
Only one of those is the customer genuinely needing more space. The other three are cleanup, and clearing them buys more headroom than the increase would have, at no cost.
The count of files matters as much as their size
An account can be well within its disk allowance and unable to write anything, which produces a support request that makes no sense against the quota figure.
df -i /home | tail -1 for u in $(ls /var/cpanel/users); do printf '%8s %s\n' "$(find /home/$u -xdev 2>/dev/null | wc -l)" "$u" done | sort -rn | head -5
That lists accounts by file count rather than by size. A session directory, a cache, or a mail folder with hundreds of thousands of tiny files is the usual cause.
It matters at the server level too, since the count is shared. One account exhausting it stops every account on the machine from writing, and the quota screen shows nothing wrong for any of them. Understanding inodes deals with finding the directory.
Recalculate before believing the figure
Quota numbers drift, and a figure that is plainly wrong is usually stale rather than a fault in the account.
/scripts/fixquotas quota -s -u username repquota -a 2>/dev/null | head -20
Usage counted against a limit is maintained as files change, and it can lose track after a restore, a large move, or an interrupted operation. The result is an account reported as full while the directory plainly is not.
Recalculate before investigating anything else when the number and the directory disagree. It resolves the case entirely often enough to be the first step rather than the last, and it is harmless when the figure was correct all along.
