Bandwidth and quota: seeing the ceiling before a site hits it
Screen walkthrough with on-screen captions, no narration. Plays on this page, muted, no sign-in needed. Every name, address and figure on screen is an example.
Two meters describe how close each of your accounts is to a wall: bandwidth and quota. Both are visible from the dashboard, both take seconds to read, and both are almost universally ignored until something stops working. Reading them on a schedule turns a class of emergency into a class of scheduling.
What each number is actually measuring
| Meter | Counts | Resets | Hitting it looks like |
|---|---|---|---|
| Bandwidth | Traffic served in the current period | Yes, each period | The site stops serving until the period turns over |
| Disk quota | Space in use right now | No, it is a level | Writes fail: uploads, logs, mail, database |
The difference in the reset column drives the difference in response. A bandwidth problem has a deadline and then goes away. A quota problem does not fix itself and gets worse while you think about it.
Read bandwidth as a shape, not a total
The total on its own tells you very little. What is informative is the shape over time, because the shape names the cause:
- Gradual climb across many accounts. Genuine growth. Plan for it rather than react to it.
- One account jumping with no traffic change. Almost always a crawler, a backup pulling copies out, or a large file somebody linked directly.
- Everything jumping on the same day. Something you applied to all of them, or something scanning the whole estate.
- A flat line where there should be movement. The site is not being served at all. That is a different and more urgent finding.
Two of those four are not traffic problems, which is why reaching for a bigger plan as the first response is usually the wrong move. Separating real load from noise is covered in Diagnostics.
Quota is not only about bytes
The space figure is the one on the dial, but on a content network the limit that bites first is often the number of files rather than their size. Caches, thumbnails and mail stores generate enormous counts of tiny files, and an account can be nowhere near its space limit while being unable to write anything. What that limit is and how to look at it properly is set out in cPanel in Practice.
Mail deserves a specific mention. On an estate where every site has its own address and its own mailbox, mail is frequently the largest thing in the account, and nobody ever deletes it. Check it before assuming a database has grown.
The over-quota view is your early warning list
There is a dedicated view for accounts that have crossed their quota, and its value is that it is a short list you can act on rather than a wall of numbers you have to interpret. Read it as a queue, worst first, and give each entry one of three outcomes:
- Reclaim. Old backups inside the account, logs nobody reads, caches that will rebuild. The usual fastest win.
- Raise. The site has legitimately grown. Change the package rather than the single account, so the next site inherits the decision.
- Move. The account has outgrown a shared ceiling entirely. When that is the honest answer is set out in Scaling Up.
Look before the month ends, not after
Both meters are most useful read early. A bandwidth figure checked with a week to spare leaves you options: serve a heavy file from elsewhere, block an aggressive crawler, or accept the overage knowingly. The same figure read the morning a site went dark leaves you none. Folding a two-minute look into the monthly pass in Running Your Estate is the whole discipline.
Still not sure which way to go?
Tell us what you are building. If it needs less than you think, we will say so.