CloudLinux Resource Limits: What Those cPanel Faults Actually Mean

If your site has ever felt briefly sluggish and you found a graph in cPanel labelled "faults," you have met CloudLinux. It is the software that keeps one busy account on a shared server from slowing everyone else down — and the way it does that is by giving each account its own hard resource limits. Hitting a limit is not a crash and it is not a penalty. It is the system doing exactly what it is meant to do.

This is a plain-English guide to what each limit is, how to read your own usage, and what to actually do when you keep bumping into one.

Why the limits exist at all

On shared hosting, many accounts live on one physical server. Without limits, a single site getting hammered — a traffic spike, a runaway plugin, a badly written cron job — would eat the whole machine and take every other site down with it. That is the classic "noisy neighbour" problem.

CloudLinux solves it by putting each account in its own container, called an LVE (Lightweight Virtual Environment), with a fixed slice of the server's resources. Your slice is guaranteed to you, and it is also capped — so your neighbour's bad day stays their problem, and yours stays yours. It is the same mechanism that lets us promise we do not oversell.

The limits, one at a time

CPU. Measured as a percentage, where 100% equals one full core. On our shared plans a core is 4.6 GHz — the Essential plan gets 50% of that, Elite 75%, and Executive a full 100%. Go over your share and requests queue for a moment rather than fail; you will see this as CPU faults.

Physical memory (PMEM). The RAM your account can use at once — 512 MB on Essential, 2 GB on Elite, 3 GB on Executive. This is the limit that most often shows up as a real error, because when a process cannot get the memory it needs, the page it was building fails with a 500 or 508 rather than just slowing down.

I/O (disk throughput). How fast your account can read from and write to disk, in MB per second — 1 MB/s on Essential, 5 MB/s on Elite, 8 MB/s on Executive. Database-heavy sites and large file operations hit this first.

IOPS. The number of separate disk operations per second, as opposed to raw throughput. A site doing many tiny reads and writes can hit IOPS long before it hits the MB/s cap.

Entry processes (EP). How many requests your account can actively process at the same moment. This is not your total visitors — a page usually finishes in a fraction of a second, so a handful of entry processes serves a lot of traffic. You hit the EP limit when many requests arrive and each one takes a long time to complete, which is itself usually a sign that something is slow upstream.

Number of processes (NPROC). The total count of processes your account may run at once, including cron jobs and background tasks. Runaway scripts that spawn copies of themselves are the usual cause of hitting this one.

A "fault" is information, not damage

The single most important thing to understand: when you exceed a limit, CloudLinux records a fault and briefly throttles that one resource. Your account is not suspended, your data is untouched, and nothing is broken. A CPU or I/O fault means "you were held for a moment"; a memory fault means "one request could not complete." Occasional faults during a genuine traffic spike are normal and nothing to act on.

What matters is the pattern. Faults every single day, at times when you are not getting unusual traffic, mean your plan and your site are no longer matched — and that is worth fixing.

How to read your own usage

In cPanel, open Resource Usage (sometimes shown as "CPU and Concurrent Connection Usage"). It shows a graph for each limit above and flags any you have been hitting. Switch the range to the last few days and look for two things: which resource is faulting, and whether it lines up with real traffic or happens at quiet times.

Which resource is faulting tells you where the problem is:

Memory faults usually point at a heavy application — too many plugins, an unoptimised theme, or a page that loads far more than it needs to on every request. CPU or I/O faults usually point at the database — a big WooCommerce catalogue, a forum, or a query with no index behind it. EP faults almost always mean requests are taking too long to finish, so they pile up; fixing the underlying slowness usually clears them.

Fix first, upgrade second

It is tempting to read "resource limit" as "buy a bigger plan," and sometimes that is the right call. But a lot of the time the same site runs comfortably after some tidying, and moving an unoptimised site to more resources just raises the ceiling it eventually hits again.

Worth trying before you upgrade:

Turn on caching. Our servers run LiteSpeed, and LiteSpeed Cache for your platform is the single biggest win — it serves most visitors a ready-made page instead of rebuilding it from the database every time, which drops CPU, memory and I/O all at once.

Audit your plugins and extensions. Deactivate what you are not using. One poorly written plugin running on every page load is a very common cause of memory faults.

Check your cron jobs. A job set to run every minute that takes longer than a minute will stack up and burn NPROC and CPU. Space them out or make them lighter.

Look at your database. Slow queries and missing indexes drive I/O and CPU faults. On a store or forum this is often where the real fix is.

When upgrading genuinely is the answer

If your site is already optimised, caching is on, and you are still hitting limits during normal traffic, you have simply outgrown the plan — and that is a good problem. You can move up a shared tier for more of every limit, step across to business hosting for guaranteed resources with far fewer accounts per server, or move to a VPS if you need root access as well as headroom.

You can also raise CPU or RAM on their own, without changing plan, if only one limit is the bottleneck. If you are not sure which of those fits, send us your Resource Usage screenshot and we will tell you which limit you are actually hitting and the cheapest way to stop hitting it.