Why Your Host's Unlimited Plan Has Limits, and Where They're Written Down

“Unlimited” in shared hosting is not exactly a lie. It is a word with a specific meaning that is narrower than the one you are reading it with, and the narrowing is documented — just not on the pricing page.

The exercise that makes this concrete: open a host’s plan comparison page, then open the same host’s terms of service, and read them side by side. You will usually find the marketing claim and the actual cap described by the same company, in the same month, with different numbers.

One provider, two documents, two numbers

The clearest example I found, and I am citing one provider rather than generalising because the pattern is what matters:

Source	What it says
Help centre, plan limits summary	“Max File Count: 1,000,000”
Terms of service	Accounts with “inode count in excess of 200,000” can have an adverse effect on performance

Same company. Both pages live and reachable. The number differs by a factor of five, and only one of them is a number you would find while shopping.

The help page for that same hosting tier also advertises unlimited email accounts and unmetered bandwidth, and then lists, on the same page: a maximum of 500 emails sent per hour, 25 concurrent MySQL connections, 5,000 database tables, and a 5 GB limit on a single database. Unmetered bandwidth turns out to be genuinely unmetered. Everything stored on the disk has a number attached.

Inodes: the cap that hides in the fine print

If you learn one thing about shared hosting limits, make it this one: the binding constraint is usually file count, not disk space.

An inode is a filesystem record for a file or directory. Every file you upload is one. So is every directory. So is every email you leave sitting on the server — a folder of 10,000 unread messages is 10,000 inodes, and it is nearly invisible on a disk usage graph.

That is the mechanism behind an experience that confuses a lot of site owners: you cannot receive email, and your disk usage shows you nowhere near full. No new file can be created, including the file an incoming message would be written to. cPanel’s own documentation describes exactly this failure: exceeding the hard quota means “you won’t be able to add new web pages, receive emails, install software.”

The enforcement is not a mystery — cPanel documents it as XFS filesystem quotas with a soft limit and a hard limit, giving the example isoft=100000 ihard=150000. Exceeding the soft quota still lets you write; you have crossed a warning line. Exceeding the hard quota blocks file creation outright. Two different behaviours wearing one word.

Which means there are two numbers per site, and the one you find in the knowledge base may be the soft one.

Why the cap is on files, not gigabytes

Because gigabytes are not the scarce resource. The provider is not running out of disk. It is running out of the operational cost of managing millions of small files — backups that have to walk every inode, filesystem checks that scale with inode count, and the rest of it.

That reframes a whole category of hosting advice. “Optimise your images to save space” is often the wrong instinct on a shared plan. Deleting 40,000 cached thumbnails saves time proportional to the file count, not their total size.

The practical list of inode consumers, in rough order of how often they surprise people:

• Email kept on the server rather than fetched and deleted
• Cache directories from plugins and frameworks
• Session files and temporary uploads
• Backup archives you left in your account
• A site’s worth of small images generated at multiple sizes

The CPU number means something different than you think

When a plan says 25% CPU, that is 25% of one core — not 25% of the server. The CloudLinux default, which sits underneath most cPanel shared hosting, is 100% of a single core.

So the comparison you should be making is not “my plan has a small CPU allowance.” It is “my site may use one core’s worth of CPU, shared across everything in my account.” A WordPress site with an uncached page doing thirty database queries can exhaust a third of that on a single visitor.

Note also that several providers document a tier-dependent allowance rather than a flat one, and explicitly exempt VPS and dedicated plans from the cap — “no enforced limit” — which is a rare honest signal about what you are actually buying when you upgrade.

Backups are conditional, and the condition is the interesting part

One plan-limit page states that weekly backups are created for shared accounts under 20 GB and 100,000 inodes.

Read that twice. The accounts most likely to need a restore — large, file-heavy, long-running ones — are exactly the ones that fall outside the automatic backup. The safety net has a hole shaped like the thing it is supposed to catch.

This is the single strongest argument for paying for backups on a shared plan, or for keeping your own copy entirely outside the host. It is also a line item most three-year cost comparisons omit, which is a topic for another article.

What “unmetered” is doing in that sentence

Bandwidth is genuinely unmetered on most shared plans, and that is not a trick — the economics work, because bandwidth per site is small and the limits that actually bind are CPU, entry processes, and inodes.

The word is doing a different job in the email section. “Unlimited email accounts” is true; “500 emails per hour” is also true. You may create as many mailboxes as you want, and you may send four characters’ worth of hourly volume across all of them. Both statements are documented by the same vendor on the same page.

How to audit your own plan

Fifteen minutes, no support ticket:

1. Read your host’s plan limits page for file count / inodes, MySQL connection limit, and CPU percentage. These three are the ones that bind.
2. Read the terms of service or acceptable use policy and search for “inode”, “fair use”, and “excessive”. This is where the real numbers live.
3. Check your actual inode count. df -i from a shell, or the File Usage figure in your hosting panel on cPanel-based plans.
4. Count what email is sitting on the server. If the number is in the thousands, you have a free win.
5. Search your access logs for a single day and count 508s and 500s. See the previous article on what each code means.

Do this before you hit a limit, not after. The point of knowing the number is that the failure stops being mysterious — you will recognise “cannot receive email” for what it is instead of opening a support ticket that takes three days.

When none of this applies

If your site is small, static, and you keep email somewhere else, these caps will never touch you. That is not luck; it is a design decision, and it is worth making deliberately.

The plan’s limits were always there. What changes when you read them is which architecture you choose — and whether the word unlimited is informing that choice or just decorating it.