Disk space and traffic are the limits everybody compares before buying. In practice they are not the ones that stop sites. There are three others, far less talked about, and they explain most of the «but I have plenty of space left» messages that reach us.
|
You will not find numbers here, on purpose. The values differ from plan to plan and change over time, and a number written into an article is wrong by next week. What counts is what your panel shows and what is on pricing and plans. This article explains what each limit is and how to read it.
|
Inodes: the number of files, not their size
An inode is one entry on the disk: a file, a folder, an e-mail message. An empty file uses one inode; a file of several gigabytes also uses one. The limit counts how many things you have, not how much they weigh.
Hence the situation that baffles everyone: the panel shows free disk space and the site can no longer save anything. Mail stops arriving, uploads stop working, and the error messages rarely contain the word inode.
| What burns them |
Why |
| Cache folders |
A caching plugin can write one file per page, and one per variant of that page. Thousands of tiny files, most of them long past useful. |
| Mail |
Every message is a file. On an account with several long lived mailboxes, mail is almost always the biggest slice of the inode count. |
| Backups left on the server |
That ZIP of the whole site you generated eight months ago and never downloaded, and the old-site folder sitting next to the new one. They count from the inside, file by file. |
| Dependency folders |
A modern project's dependency folder often holds more files than the entire website. If the server does not need it, do not put it there. |
| Galleries and thumbnails |
Every image uploaded generates several versions at different sizes. A thousand photo gallery can be several thousand files. |
Processes and concurrent requests
This is the limit almost nobody gets first time, because it is not measured per day: it is measured at the same instant. Your plan allows a certain number of requests to be processed simultaneously. A request that takes half a second occupies a slot for half a second; one that takes eight seconds occupies it for eight.
That is why a fast site carries far more visitors than a slow one on the same plan, and why visits per day tells you nothing about whether the plan is enough. What matters is how many overlap.
When it runs out, the extra requests are refused: the visitor gets an error page instead of the site, and seconds later everything is fine again. It is a limit you hit in bursts, which is why the site owner can almost never reproduce the complaint.
Memory and processor
The account has a memory ceiling and a slice of processor assigned to it, and they are fenced off deliberately: that is what stops a noisy neighbour taking the machine from you. The difference in how the two behave matters:
| Resource |
What happens at the ceiling |
| Memory |
The operation fails. Blank page, critical error, an import that stops halfway. It is abrupt and you notice. |
| Processor |
The operation does not fail: it is slowed down. The site keeps answering, just slowly. That is why an exhausted processor looks like sluggishness rather than an error, and why nobody suspects it. |
|
Account memory is not the PHP memory_limit. These get confused constantly. The PHP one is the most a single request may use at a time, and it exists as a brake; the account one is your total, shared by everything running at once. Raising the PHP one gives you no extra resources. It is explained in «PHP limits: memory, time, upload size and the one that fails silently».
|
Where you see all of this
| 1 |
The statistics column in cPanel, beside the icons, shows the essentials with the limit next to each value: space used, file count (the inodes), databases, e-mail accounts, subdomains. The fastest place to find out where you stand.
|
|
| 2 |
Resource Usage, under Metrics, is the one for processor, memory and concurrent requests. It plots usage against the limit over time and marks the moments you hit the ceiling. That is where the question «is the plan enough?» gets answered.
|
|
| 3 |
Disk Usage, under Files, tells you which folders are heavy. Start there before deleting anything.
|
|
| 4 |
Errors, also under Metrics, records failures caused by limits, with date and time. Cross that with Resource Usage and you usually have your answer in two minutes.
|
|
From symptom to likely limit
| What you are seeing |
Suspect |
| «I cannot save files but I have space left» |
Inodes. |
| «Mail stopped arriving and the disk is not full» |
Inodes, almost certainly. |
| «The site drops out at peak hours and recovers by itself» |
Concurrent requests. |
| «Blank page during a heavy operation» |
Memory. Could be PHP's, could be the account's. |
| «The site is slow all the time, any hour of the day» |
Processor, or the site itself. More often the site itself. |
|
Clean up before you upgrade. Emptying trash and spam across every mailbox, deleting old backups left on the server and clearing the cache folder tends to hand back a surprising number of inodes. Half an hour of work, and it saves a bigger bill every month thereafter.
|
And when cleaning is no longer enough, then yes: the site outgrew the plan. At that point the honest answer is a bigger plan, not more squeezing. The limits of each are on hosting plans; if what you need is to set the limits rather than accept them, the conversation becomes a VPS.
|
Want to know which limit you are hitting? Give us the domain and we will go through your account's numbers with you.
Open a support ticket
|
Português
English
