How to Read Hosting Resource Limits: CPU, RAM, Inodes

What do hosting resource limits actually measure?

Hosting resource limits define how much of a shared server your account may use at once: CPU as a percentage of a core, RAM in megabytes, inodes as a raw count of files, plus I/O and process caps. They exist so one busy site cannot starve its neighbors. To read them correctly, you need to know that almost none of these numbers mean what their marketing labels suggest.

On shared and reseller hosting, your account runs inside a container — usually CloudLinux's Lightweight Virtual Environment (LVE). The host slices a physical server into hundreds of these cages, each with its own ceilings. When you exceed a ceiling, the system does not crash the server; it throttles or kills your processes. That is why 'unlimited' plans still suspend accounts: the disk may be unmetered, but CPU, entry processes, and inodes are very much capped underneath.

The practical skill is matching the label to the real constraint. 'Unlimited bandwidth' rarely bites; an 'EP 20' entry-process limit on a WooCommerce store absolutely will. Read every plan as a stack of separate budgets, and find the smallest one — that is your true ceiling.

How to read CPU limits (cores, %, EP and NPROC)

CPU on shared hosting is almost never sold in GHz. Instead you get a percentage of one CPU core inside your LVE container. A common entry plan grants 100% of one core; mid-tier plans give 200–400% (the equivalent of 2–4 cores). When your scripts demand more, CloudLinux throttles them — requests queue and slow down rather than failing outright.

Two limits matter more than the headline CPU figure, and most hosts bury them:

• EP (Entry Processes): the number of requests that can hit your dynamic scripts (PHP, etc.) simultaneously. A typical cap is 20. Each page that runs PHP holds one EP slot until it finishes. A slow database query that ties up slots will return 508 Resource Limit Reached errors to new visitors even while your CPU sits at 10%.
• NPROC (Number of Processes): the total processes your account may have running, often 100–200. Cron jobs, email, and PHP workers all count.

So when you read a plan, do not stop at '2 CPU cores.' Ask for the EP and NPROC numbers too. For a busy store or forum, EP is frequently the wall you hit first. A short-lived spike of 30 concurrent checkouts on an EP-20 plan means a third of your shoppers see an error page.

Where to see your live CPU usage

In cPanel, open Statistics > Resource Usage (or 'CPU and Concurrent Connection Usage'). It shows whether you hit your CPU, EP, NPROC, I/O, or memory limit in the last 24 hours, and which faults occurred. A row of red 'faults' against EP tells you to optimize concurrency or upgrade — not to buy more disk.

How to read RAM and I/O limits

RAM (physical memory) on shared hosting is capped two ways: a per-process ceiling and a per-account ceiling, commonly 1GB on starter plans and 2–4GB higher up. The trap is that PHP itself has its own memory_limit (often 256MB or 512MB) inside that account budget. A single image-heavy WordPress import can blow the PHP limit and die with a white screen, even though your account RAM looks fine.

Crucially, when a process exceeds the memory cap, CloudLinux kills it — quietly. There is rarely a banner saying 'out of memory.' Instead you get intermittent HTTP 500 errors, failed cron jobs, or truncated backups. If errors are random and load-dependent, suspect memory before anything else.

I/O and IOPS are the most overlooked limits and often the real bottleneck:

A site on a fast NVMe host with a generous I/O cap will feel quicker than the same site on a 'bigger' plan throttled to 1 MB/s. When comparing hosts, ask about NVMe storage and the I/O/IOPS ceiling, not just the gigabytes of space. This is one area where a performance-focused host on modern NVMe with LiteSpeed — the kind of stack LaunchPad Host runs — gives you headroom the spec sheet alone won't reveal.

What are inodes, and why do they suspend accounts?

An inode is a filesystem record for a single file or directory. Your inode count is simply the total number of files and folders your account owns — every PHP file, image, email message, cache entry, and log. Most hosts set a soft cap around 200,000–250,000 inodes and a hard cap where they stop backups or suspend the account.

Inodes catch people off guard because the usual culprits are invisible:

• Email: each message is one inode. A neglected mailbox with 80,000 emails is 80,000 inodes.
• Cache and sessions: page caches and PHP session files can generate tens of thousands of tiny files.
• node_modules and backups: a single JavaScript project can hold 30,000+ files; old on-server backups quietly double your count.

The headline 'unlimited storage' is almost always governed by an inode cap in the fine print. You can be using 5GB of a '100GB' plan and still get suspended for having 300,000 small files.

How to check and control your inode count

In cPanel, the right sidebar under Statistics shows 'File Usage' (your inode count) against the limit. To bring it down: empty spam and trash mailboxes, clear stale cache directories, remove old backups from the server, and delete unused node_modules folders. Watching this number monthly prevents the nastiest surprise in shared hosting — a working site taken offline not for traffic, but for file count.

How to compare plans by their real ceilings

Marketing pages compete on the easy numbers — disk and bandwidth — because those rarely constrain anyone. Read past them. Build a short checklist and ask the host directly; a transparent provider will answer in minutes, and reluctance to share these figures is itself a signal.

1. CPU: How many cores (or what %) per account? Is it burstable?
2. EP / NPROC: What is the entry-process and process-count cap? (This predicts how many concurrent visitors you can serve.)
3. RAM: Per-account and per-process limits, plus the default PHP memory_limit.
4. I/O and IOPS: The throughput cap and whether storage is NVMe.
5. Inodes: Soft and hard caps, and whether email counts toward them.

Match the answers to your workload. A static brochure site is happy almost anywhere. A membership site, forum, or store lives and dies by EP, I/O, and RAM. If you are choosing hosting with privacy in mind, the same diligence applies — a credible offshore or privacy host should publish clear resource limits and a plain acceptable-use policy alongside its NVMe and LiteSpeed specs, so you know exactly what you are renting. LaunchPad Host's offshore and privacy-forward plans are built on that performance stack and are crypto-friendly for anonymous billing, which suits projects that want both headroom and discretion within lawful bounds.

Read the limits before you read the price. A plan with double the disk but a quarter of the entry processes is the worse deal for any site that actually does something.