Understanding cPanel Resource Usage CPU, Memory, and Entry Processes

Every Ultra Web Hosting shared plan runs on CloudLinux, which draws a fence around each account so no single site can hog the whole server. That fence is why you sometimes see CPU, memory, or Entry Process numbers climbing in cPanel, and why a busy site can slow down or throw a 508 error even though the server itself is fine. This guide explains what each metric means in plain language, where to read your usage in cPanel, what actually causes it to spike, and the practical steps to bring it back down before you start thinking about a bigger plan.

01. Why Shared Hosting Has Resource Limits

On a shared server, dozens of accounts live on the same physical machine. Without limits, one site having a bad day, a traffic spike, a runaway script, or a bot flood, could consume all the CPU and memory and drag every other site on the box down with it. That is the classic "noisy neighbor" problem.

Ultra Web Hosting runs CloudLinux, which solves this with a feature called LVE (Lightweight Virtual Environment). LVE puts each cPanel account in its own isolated container with a defined slice of CPU, memory, and process capacity. The important thing to understand is that this cuts both ways:

02. The Key Metrics, Explained Plainly

cPanel reports six numbers under Resource Usage. Here is what each one actually means for your site, without the jargon:

• CPU (Speed %) - how much processing power your account is using, shown as a percentage of your allowed share. A page that runs heavy PHP or slow database queries burns CPU. Sustained 100% means requests are waiting in line for a processor slot.
• Physical Memory (RAM) - the working memory your PHP processes hold. Each concurrent request needs a chunk of RAM. Hit the memory cap and new processes are refused, which shows up as errors or blank pages.
• Entry Processes (EP) - the number of dynamic requests running at the same instant. Every PHP page load, cron hit, or dynamic request counts as one entry process while it is being served. This is a small number (often a limit of 20 to 30) and it is the one most sites hit first. More on this in Section 07.
• Number of Processes (NPROC) - the total count of all processes your account has open, including PHP workers, shell tasks, and cron jobs. Different from EP: NPROC counts everything running, EP counts only active dynamic requests.
• I/O (disk throughput) - how fast your account is reading from and writing to disk, in bytes per second. Heavy logging, large file operations, or an uncached site hammering the database can push this up.
• IOPS (I/O operations per second) - the number of separate read/write operations per second, regardless of size. Lots of tiny file reads (a site with thousands of small cache files, for instance) can hit the IOPS cap even when total throughput is modest.

03. Where to See Your Usage in cPanel

You do not have to guess. cPanel shows both a live snapshot and a rolling 24-hour history.

1. Log in to cPanel.
2. In the search box at the top, type Resource Usage and open the tool (it also sits under the Metrics section).
3. The overview page tells you at a glance whether your site has been limited in the last 24 hours. A green check means you stayed under every limit; a warning means you hit one.
4. Click Details (or Current Usage) to open the graphs. Each metric from Section 02 gets its own chart, plotted against your account's ceiling for that metric.
5. Use the time-range selector to switch between the last hour, last 24 hours, and longer windows. A single tall spike reads very differently from a flat line pinned at the top.

The Statistics sidebar on the main cPanel page also shows quick counters for disk usage, inodes, and other allowances, which is a fast way to spot a disk or inode problem without opening the full tool.

04. What Happens When You Hit a Limit

When your account reaches one of its caps, CloudLinux does not switch your site off. Instead it applies back-pressure:

• Requests queue. New page loads wait for a free slot, so the site feels slow or pages hang partway through loading.
• Requests are briefly denied. If the queue is full, the server returns a 508 Resource Limit Reached (or sometimes a 503) rather than waiting forever.
• It clears itself. As soon as usage drops back under the limit, everything serves normally again. No action is needed to un-throttle.

The key point: this is a throttle, not a suspension. Your account stays active, your files are untouched, and your email keeps flowing. The site just runs at reduced speed while it is over the line.

05. The Most Common Causes of High Usage

Almost every high-usage account we look at traces back to one of these:

• An unoptimized, uncached WordPress site. With no page cache, every visit rebuilds the page from scratch with fresh PHP and database work. This is the number one cause by a wide margin.
• A traffic spike. A post going viral, a newsletter blast, or a sale sends a wave of simultaneous visitors, each holding a PHP worker.
• A heavy or badly written plugin. A single slow plugin (related-posts, some page builders, some security scanners) can dominate CPU on every request.
• A bot or crawler flood. Aggressive scrapers, AI crawlers, or a misbehaving search bot can hit hundreds of pages a minute, each one an uncached dynamic request.
• wp-cron running too often. WordPress fires its scheduled tasks on visitor page loads by default. On a busy or a mistuned site this piles extra PHP work onto normal traffic.
• A runaway script. A stuck import, an infinite loop in custom code, or a cron job that never finishes can pin CPU on its own.
• WooCommerce dynamic pages. Cart, checkout, and account pages cannot be fully cached, so a busy store naturally runs more PHP than a brochure site.

06. How to Reduce Your Usage

Work down this list in order. The first item alone resolves most cases.

1. Add a page cache. A caching plugin stores a ready-made HTML copy of each page and serves that instead of rebuilding it in PHP every time. This is the single biggest win for CPU and Entry Processes. Our guide "The Best WordPress Caching Plugins" walks through the options and setup.
2. Run fewer, lighter plugins. Deactivate anything you are not using, and replace known-heavy plugins with leaner alternatives. Every active plugin runs on page loads whether you use its feature or not.
3. Optimize the database. Clear post revisions, expired transients, spam comments, and orphaned metadata. A bloated database makes every query slower, which burns CPU and I/O.
4. Block bad bots. Rein in aggressive crawlers with a sensible robots.txt, and block the worst offenders by user agent. Cutting bot traffic directly cuts uncached PHP hits.
5. Control wp-cron. Disable the default on-visit trigger and run WordPress cron on a real schedule instead, so scheduled tasks stop piggybacking on visitor page loads.
6. Optimize your images. Oversized images drive up I/O and bandwidth and slow the whole page. Compress and correctly size them; article #276 covers image optimization along with the rest of a WordPress performance pass.

07. Entry Processes: The One People Hit Most

Entry Processes deserve their own section because they are the limit most sites hit first, and the number surprises people because it looks so small. If your plan allows 20 Entry Processes, that means only 20 dynamic requests can be in flight at the same instant. It is not 20 visitors per second, it is 20 requests being actively processed at once.

The math is about how long each request takes to finish:

• A page that finishes in 100 milliseconds frees its slot ten times a second. One slot can serve roughly 10 requests per second.
• A slow page that takes 2 seconds (a heavy query, a laggy plugin) holds its slot the whole time, so it serves only 0.5 requests per second per slot.

So Entry Processes spike for two reasons: slow requests that hold their slot too long, or many simultaneous visitors all needing PHP at once. Both push you toward the ceiling.

08. Disk and Inode Usage Crossover

Two related allowances live alongside the performance metrics and are easy to confuse with them. Disk space is the total size of your files. Inodes are the total count of files and folders, regardless of size. You can be well under your disk quota and still hit the inode limit if you have hundreds of thousands of tiny files (old cache files, backup fragments, mail, log files).

These matter to resource usage because a site drowning in files is slower to back up, slower to scan, and can push up I/O and IOPS. If your Statistics sidebar shows inodes or disk near the ceiling, clearing that out often helps performance as a side effect. Article #40 covers understanding and managing disk space, including how to find what is eating your inodes.

09. Reading the Trend and Finding the Offender

The 24-hour and longer graphs in the Resource Usage tool are how you go from "my site was slow" to "here is exactly what did it." Read them like this:

1. Look at the shape over time. One tall spike at a known moment (you published a post, a newsletter went out) is a traffic event. A flat line pinned at the ceiling all day is a chronic problem, usually a missing cache or a heavy plugin.
2. Match the spike to the clock. Note the time a limit was hit, then cross-reference your access logs and any scheduled tasks. A spike that lands on the same minute every hour points at cron; one that tracks your traffic points at caching.
3. Correlate the metrics. CPU and I/O rising together usually means database work. Entry Processes maxed while CPU is moderate means slow requests holding slots. The combination tells you where to look.
4. Isolate the script. If usage is constant and unexplained, disable plugins one at a time (or bulk-disable and re-enable in groups) and watch the graph. The one whose removal flattens the line is your offender.

10. When You Have Outgrown Shared Hosting

Sometimes the numbers are not a bug to fix. A healthy, well-optimized site that keeps pressing against its limits has simply grown past what a shared slice can comfortably serve. That is a good problem, and the answer is more resources rather than more tuning.

A busy store is the classic case: our "Running WooCommerce on Shared Hosting" guide covers how far you can push a store on a shared plan, and where the line sits. When you are ready to compare tiers, article #481 lays out shared versus VPS versus dedicated and which fits which kind of site.

Quick Recap: Resource Usage in Six Points

If you only take six things from this guide, take these:

1. Limits protect everyone. CloudLinux LVE gives each account its own slice, so you cannot be crushed by a noisy neighbor and cannot crush anyone else.
2. A limit is a throttle, not a suspension. Requests queue or briefly return a 508, then recover on their own once usage drops.
3. CPU and Entry Processes are what you will hit. Read them in the cPanel Resource Usage tool, and mind the shape of the graph over time.
4. Caching is the biggest lever. A cached page never touches PHP, so it lowers both CPU and Entry Processes at once.
5. Then trim the rest. Fewer plugins, a clean database, controlled wp-cron, blocked bad bots, and optimized images.
6. Know when to upgrade. An already-optimized site that still caps out has outgrown shared hosting; that is when VPS or dedicated makes sense.

Last updated July 2026 · Browse all Hosting Control Panel articles