Understanding cPanel Resource Usage Metrics

What the Resource Usage page measures

On shared hosting, hundreds of accounts can share one physical server. To stop a single busy site from slowing everyone else down, many hosts run CloudLinux OS, which places each cPanel account inside a Lightweight Virtual Environment (LVE). The LVE caps how much CPU, memory, disk throughput and how many processes the account can use at any moment.

cPanel exposes these limits on the Metrics > Resource Usage page (sometimes labelled CPU and Concurrent Connection Usage on servers without CloudLinux). If your site shows intermittent “Resource Limit Is Reached” errors, random 500 errors or slowdowns at busy times, this page is where you find out why.

The exact limit values are set by your host and vary by plan. The numbers below are illustrative; always check your plan or the page itself for your actual limits.

The six core LVE limits

Some servers also show VMEM (virtual memory). Modern CloudLinux setups mostly rely on PMEM, and many hosts set VMEM to unlimited, so focus on PMEM unless your host says otherwise.

CPU: speed, not capacity

CPU limits are expressed relative to a single core. A limit of 100% means the account can use the equivalent of one full core; 200% means two cores. When the account reaches the cap, CloudLinux does not kill processes. It slows them down, so a page that normally renders in 300 milliseconds might take several seconds.

Because CPU throttling only causes slowness, it is easy to miss. Sustained CPU usage near the limit usually points to one of these:

• Pages generated on every request with no page caching.
• Heavy plugins or extensions doing work on each page load.
• Bots and crawlers hitting search, filter or cart URLs that cannot be cached.
• Cron jobs such as image optimisation, imports or backups running at peak times.

Entry processes and NPROC

An entry process is counted when something enters your LVE, typically a PHP request handled by the web server. If your EP limit is 20 and 20 PHP requests are already running, request number 21 is refused with a 508 error. EP is about concurrency, not visitors per day: one hundred visitors loading pages in quick succession can stay well under the limit if each request finishes quickly.

That is why EP faults are usually a speed problem in disguise. If each request takes two seconds, concurrency builds up fast. If it takes 200 milliseconds, the same traffic uses a tenth of the slots. Caching and faster queries are the most effective fixes.

NPROC counts every process and thread in the account: PHP workers, cron scripts, SSH sessions, mail delivery and anything else. It is always set higher than EP. NPROC faults often come from runaway cron jobs that start new copies before old ones finish, or from scripts spawning many child processes.

Physical memory (PMEM)

PMEM is the total RAM used by all processes in the account, including the page cache attributed to it. When the account reaches the limit, new memory allocations fail. In practice that shows up as PHP fatal errors, white screens, 500 or 503 responses, or a script that simply stops.

Note the difference from the PHP memory_limit setting. memory_limit caps a single PHP process; PMEM caps the whole account. Ten PHP workers each allowed 256 MB could theoretically request far more than a 1 GB PMEM limit. Raising memory_limit therefore does not fix PMEM faults and can make them more frequent.

IO and IOPS

IO limits throughput, the amount of data read or written per second. IOPS limits the number of individual operations. A large backup archive mostly consumes IO; thousands of tiny file reads, such as a cache with many small files or a session directory, mostly consume IOPS.

When either limit is reached, disk operations are queued and everything that touches the disk becomes slower. Common causes include:

• Full account backups or large zip and unzip operations.
• Database queries without proper indexes, which force large table scans.
• File-based caching plugins writing and deleting many small files.
• Log files growing very quickly because of errors or debug mode left on.

Reading faults and history

The Resource Usage page usually opens with a summary telling you whether the account hit any limits recently. The detailed view shows graphs per metric and a table of faults, which are counts of how many times each limit was reached in a given interval.

• Occasional faults during a traffic spike are normal and may not need action.
• Repeated faults every day at the same time often match a cron job or a crawler schedule.
• Constant faults mean the site regularly needs more than the plan provides, or something is misbehaving.

Match fault times against your access logs (Metrics > Raw Access or Visitors) and your cron schedule. On servers where SSH is available, you may also be able to check current usage with CloudLinux tools if your host enables them:

lveinfo --period=1d --show-columns=ID,uEP,lEP,EPf,uCPU,lCPU,CPUf,uPMem,lPMem,PMemF

Most shared hosting users do not have access to lveinfo; it is typically an administrator tool. If it is unavailable, the cPanel page provides the same data in graphical form.

How to reduce limit hits

Before upgrading, work through the changes that usually make the biggest difference:

1. Enable full-page caching for anonymous visitors, using your CMS’s caching plugin or a server-level cache if your host provides one.
2. Use a current PHP version through Select PHP Version or MultiPHP Manager, and enable OPcache if it is offered.
3. Control bots: review access logs for aggressive crawlers, rate-limit or block abusive ones, and disallow crawling of endless filter URLs in robots.txt.
4. Reschedule heavy cron jobs to quiet hours, and make sure they cannot overlap. A lock file is a simple safeguard:

*/15 * * * * flock -n $HOME/.cron.lock /usr/local/bin/php $HOME/scripts/import.php

5. Optimise the database: remove bloat like expired transients and old revisions, and add indexes for slow queries.
6. Offload static files to a CDN so images and scripts do not consume your account’s resources.
7. Disable debug logging on production sites once a problem is fixed.

If usage remains high after optimisation, that is a genuine capacity signal. Moving to a plan with higher limits or a VPS may be justified; our guide to VPS hosting explains when that step makes sense.

When to contact your host

Some situations are worth raising with support rather than solving alone. Ask your host to review the account if faults appear with no matching traffic or cron activity, if usage is high while the site is in maintenance mode, or if the graphs show a sudden jump after no changes on your side. These patterns can indicate a compromised account running unwanted scripts, which needs a malware scan as well as resource tuning. When you contact support, include the fault times and the metrics affected, which makes the investigation much faster.

Keeping an eye on your hosting over time

Resource limits are only one part of hosting health. It also helps to know exactly which provider and server a site runs on, and when the plan renews. A TLDix hosting lookup identifies the host behind a domain, which is useful when you manage sites for clients and need to know whose limits apply. Review the Resource Usage page after any major change, such as a new plugin, a marketing campaign or a theme update, so you can catch new faults before visitors notice them.