Read cPanel Resource Usage Before You Upgrade Hosting

If your site feels slow on shared hosting, a bigger plan is not always the answer. On many hosts your control panel already records which resource ran short and when, so you can see the cause before you spend any money. That record sits in a small plugin most people never open.

Before you pay for a bigger plan, read the CPU, memory and entry process graphs and the fault snapshots to see which limit your site actually hits. Sometimes the answer is "yes, upgrade." Often it is "one plugin or one scheduled task is eating the whole budget."

By the end of this guide you will be able to find that plugin, read each chart, match a fault to a first fix, and send your host one clear message if you still need help.

Heads up: everything below applies only to hosts that run CloudLinux with its LVE Manager resource plugin. CloudLinux is a server operating system built for shared hosting. If your host does not use it, you will not see these screens. Ask your host first, and skip to the section on other hosts if the answer is no.

What is a shared hosting resource limit, really?

On shared hosting, many accounts live on one server. Each account gets a fair share of the server so that one busy site cannot slow down everyone else.

CloudLinux does this with something called an LVE. The CloudLinux docs describe it as "a kernel level technology developed by the CloudLinux team." In plain words, it is a fenced box around your account. Your scripts run inside the box, and the box has limits.

Think of an apartment building with one big water tank. Each flat has its own meter and its own daily allowance. If your flat uses its allowance, your taps slow to a trickle, but your neighbours still have water. The building manager can also show you a log of the exact hours you ran out.

The resource usage plugin is that log. It shows how much you used, what your allowance was, and every time you went past it.

When you go past a limit, the system records a fault. The CloudLinux Manager docs say: "When a CloudLinux OS user hits LVE limits, appropriate faults are generated." A fault is simply a counted moment where your site wanted more than its share.

Here are the limits you will meet, with the wording from the CloudLinux limits page:

• SPEED: "CPU speed limit, relative to a single core," as the docs begin it. CPU is the processor, the part that does the thinking.
• PMEM: physical memory, the real RAM your processes hold. The docs note it "also includes shared memory and disk cache."
• VMEM: virtual memory, the total memory your processes have reserved, used or not.
• IO: "IO throughput - combines both read & write operations." This is how fast your account reads from and writes to disk.
• IOPS: "Restricts total number of read/write operations per second." This counts disk operations instead of measuring their size.
• EP: "Limit on entry processes. Usually represents max number of concurrent connections to apache dynamic scripts." In plain words, how many dynamic requests or scripts are inside the web stack at the same moment. This is not a unique-visitor count: one visitor can create several requests.
• NPROC: "Max number of processes within LVE." A process is one running program.

Why this matters: each limit points to a different kind of problem. More CPU will not fix a memory fault. More memory will not fix an entry process fault caused by a flood of bot traffic. If you know which limit you hit, you buy the right fix.

Before you start

Gather these few things first. It takes five minutes and saves a lot of guessing.

• Confirm with your host that your account runs on CloudLinux with the LVE Manager plugin. This is the one thing you must not skip.
• Your control panel login, the username and password you use for cPanel or your host's panel.
• A rough time when the site was slow or showed errors. "Tuesday evening around 9" is good enough.
• A note of your current plan name and what it promises. Your host's plan page or invoice usually lists it.
• A recent backup of your site, in case you change plugins or settings later.
• About 30 minutes of quiet time to read the charts properly.

Quick tip: if you do not remember when the site was slow, check your inbox. CloudLinux can send LVE Stats emails when you hit limits, and those emails give you a starting date.

Finding and reading your usage, step by step

Step 1: Find the resource usage plugin

Log in to your control panel. The CloudLinux docs give the user path as: "Go to your control panel and click CPU and concurrent connection usage."

The label you see may be different. Hosts change themes and names, so look for something like "Resource Usage" or "CPU and concurrent connection usage" in the metrics or statistics area. If you use the search box at the top of cPanel, try typing "usage" or "CPU".

Click it. You should see a page with three tabs: Dashboard, Current usage and Snapshot.

If you see none of this, your host may not run CloudLinux, or the plugin may be hidden for your plan. Ask them before you go further.

Step 2: Check the Dashboard first

Open the Dashboard tab. The docs say to "go to the Dashboard tab to see the general condition of your site."

This tab answers the first question fast: is your site being limited right now? The docs say that if your site is limited, this shows on the Dashboard.

If the Dashboard says everything is fine, that is useful, but it does not rule out an earlier limit hit. Open Current usage and choose the historical period when the slowdown happened. If that period also shows no faults, investigate other causes such as a slow external service, a large uncached page, DNS, or the visitor's own connection.

Step 3: Open Current usage and set the timeframe

Open the Current usage tab. This is where the charts and the usage table live.

The docs say: "You can filter charts and the Usage table by timeframe and time unit (day, hour, minute)." Set the timeframe so it covers the slow period you noted earlier.

Start wide, for example the last week by day. Then narrow down to the slow day by hour, and then to the slow hour by minute. Each step makes the problem easier to see.

You should now see charts for CPU, Virtual Memory, Physical Memory, Input/Output, Io operations, Entry Processes and Processes. Under them sits a table.

Step 4: Read the table

The Current Usage table has the columns Description, Usage, Limit and Fault. The usage history table uses short headers:

• From-To: the time window for that row.
• A: average usage in that window.
• L: your limit.
• F: the number of faults.

The resources listed include SPEED, I/O, IOPS, NPROC, EP and PMEM. On cPanel you may also see Inodes, but only when your host has turned that on and set a value. An inode is one file or folder, so this counts how many files you store.

Scan the F column first. A row of zeros is a quiet hour. A row with a number above zero is where your attention should go.

Step 5: Look at the Snapshot tab

The Snapshot tab is the most useful part, and the part most people miss. The docs describe it this way: "Go to the Snapshot tab to see server snapshots with processes list and database and HTTP queries."

Snapshots are taken when you hit LVE limits. So each snapshot is a picture of what your account was doing at the exact moment it ran short.

Pick a snapshot near a fault. Read the process list, the database queries and the web requests. You are looking for repeats: the same script name, the same query, or the same page showing up again and again.

Reading the charts

Each chart shows several coloured lines. The legend in the docs gives green as average usage, red as the limit and blue as database, plus a green-cyan entry labelled "faults (limit violations)". So the green-cyan marks are the moments you broke through the limit.

There is also a Faults chart that shows all faults together. It is a good first stop when you want to see the whole picture at once.

Here is how I read each chart. This is my own advice from years of looking at these screens, not something from the CloudLinux docs.

• CPU: if the average line rides close to the red limit line for long stretches, your site is doing a lot of work per visit. Heavy plugins, uncached pages and busy background tasks are the usual suspects.
• Physical Memory: steady high memory with faults often means a few large PHP processes, such as an import, a backup plugin, or a page builder loading many parts at once.
• Virtual Memory: faults here, with physical memory looking normal, often point to one script asking for a big block of memory at once.
• Input/Output and Io operations: spikes often line up with backups, large file uploads, log writing, or database work that reads many rows.
• Entry Processes: this counts concurrent dynamic requests entering execution, not unique people. One visitor can create several requests. Sharp bursts can come from bots, crawlers or an uncached busy page; a flat plateau at the limit can mean requests are finishing too slowly and piling up.
• Processes: a high count can come from scheduled tasks starting on top of each other, or from many PHP workers alive at once.

Why this matters: a fault on its own does not mean you must upgrade. One fault a week during a backup is different from fifty faults an hour every evening. Look at how often, how long and when.

A made-up example

This is an invented scenario, to show how the pieces fit together.

Sara runs a small recipe blog. Every night around 2 AM her site feels slow, and her host sends her a limit email. She is about to buy the next plan up.

She opens the plugin first. The Dashboard shows her site is being limited. In Current usage, filtered by hour, the EP chart shows green-cyan fault marks only between 2 AM and 2:30 AM. CPU and memory look calm.

In the Snapshot tab she sees the same backup and sitemap scripts in every snapshot from that window, along with many requests to the same URL. Her site is not too big for its plan. Two scheduled jobs are starting at the same time and stacking up.

She moves one job to a different hour, and the faults stop. No upgrade needed.

Matching the fault to the fix

Once you know which limit you hit, you can pick a first thing to try. These are my suggestions, not rules from CloudLinux. Always take a backup before changing plugins or settings.

• SPEED (CPU) faults: start with caching, so each visit does less work. Then check which plugins run on every page and remove the ones you do not need. Our guide on how to improve website speed walks through the common wins.
• PMEM or VMEM (memory) faults: look at the Snapshot tab for the script that was running. Large imports, backup plugins and image tools are common causes. Try running them at a quiet hour, or in smaller batches.
• EP (entry process) faults: check for bot traffic and make sure pages are cached. Also check whether requests are slow to finish, because slow requests hold their entry slot longer.
• NPROC (process) faults: look at scheduled tasks. If you run WordPress, its built in scheduler runs on page loads. The WordPress handbook says "WP-Cron does not run constantly as the system cron does; it is only triggered on page load." On a busy site that can mean many runs. Our guide to setting up a real cron job for WordPress explains the change.
• IO or IOPS faults: check when backups run and how large they are. Look for plugins that write a lot of logs. Look at database queries in the snapshot that read many rows.
• Faults in many places at once: this is the honest case for more resources. If you have already cached, trimmed plugins and spaced out scheduled tasks, and faults still show up across CPU, memory and EP during normal traffic, your site has outgrown the plan.

If your host does not run CloudLinux

Without CloudLinux you will not have this plugin, but you can still ask the same questions: what was busy, when, and why.

Your access log. Apache's docs say "The server access log records all requests processed by the server." Each line shows the client address, the time, the request line and the status code. Open it for your slow period and look for one address or one URL repeating many times. Status codes starting with 5 are server errors, which the Apache docs list as 5xx. Ask your host where your access log lives, because the location depends on how the server is set up.

The error log. Apache calls this the place where the server "will send diagnostic information and record any errors that it encounters in processing requests." It is the first place to look when pages break.

top, if you have shell access. On a VPS, or a shared account with SSH, you can watch live usage with top. Its manual describes it as "a dynamic real-time view of a running system." To see only your own processes, run it with -u and your username. To save one snapshot to a file during a slow moment, use batch mode with one frame:

top -b -n 1 -u yourusername > top-snapshot.txt

Replace yourusername with your account name. In the output, %CPU is each task's share of CPU time, RES is the physical memory it holds, and VIRT is "the total amount of virtual memory used by the task."

The MySQL slow query log. If your database is the suspect, the MySQL manual says the slow query log "consists of SQL statements that take more than long_query_time seconds to execute." The default for long_query_time is 10 seconds. On shared hosting you usually cannot turn this on yourself, so ask your host.

If you are on a VPS and memory is the real limit, our guide on how to increase VPS RAM safely covers the next step.

How to check it worked

After you make a change, give it time. A fix made at noon tells you nothing until the next busy period has passed.

Then go back to the same plugin. Open Current usage, set the same timeframe and time unit you used before, and compare.

What you hope to see:

• The F column for the resource you fixed shows fewer faults, or none, in the same time window.
• On the chart, fewer green-cyan fault marks during the period that used to be bad.
• The average line sitting further below the red limit line.
• The Dashboard no longer showing your site as limited.

Heads up: if faults on one resource drop but faults on another rise, your fix may have moved the load around. For example, a cache that builds pages in big batches can trade CPU faults for IO faults. Look at the new resource's snapshots and adjust.

Troubleshooting

I cannot find the plugin

Symptom: no "CPU and concurrent connection usage" or similar entry in your control panel. Likely cause: your host does not run CloudLinux, has renamed the item, or has hidden it for your plan. Fix: search the panel for "usage" or "CPU", then ask your host directly.

The charts are empty or flat

Symptom: you open Current usage and see little or nothing. Likely cause, in my experience: the timeframe does not cover the period you care about, or the site had very little traffic then. Fix: widen the timeframe, switch the time unit to day, and then zoom in.

I see faults but the site felt fine

Symptom: the F column shows a few faults, but you never noticed slowness. Likely cause, in my experience: short spikes during backups or bot visits that ended quickly. Fix: note the times. If they repeat at the same hour, look at what is scheduled then. A few scattered faults may not need any action.

The site felt slow but there are no faults

Symptom: zero in the F column for the slow period. Likely cause, in my experience: the slowness is outside your account limits, for example a slow external service, a large uncached page, a DNS problem, or the visitor's own network. Fix: test the page from another device and network, and look at page weight and caching, since those do not depend on limits.

I keep getting limit emails and want them to stop

Symptom: frequent LVE Stats emails. Fix: the docs say you can turn them off through "Resource Usage client plugin | Options | LVE Stats Email Notifications." At the time of writing (13 November 2026), the docs say this needs lvemanager 7.3.0-1 and lve-stats 4.1.4-1 on the server, so the option may not appear on older setups. My advice: fix the cause before you silence the alerts.

The Snapshot tab is empty

Symptom: no snapshots to read. Likely cause: snapshots are taken when limits are hit, so a quiet period may have none. Fix: pick a timeframe that includes faults, then check the Snapshot tab again.

Pro tips and when to ask your host

• Take a screenshot of the Dashboard, the busy chart and one snapshot before you change anything. It gives you a clear before and after.
• Write down your current limits from the L column. When you compare plans later, you can check whether the bigger plan actually raises the limit you hit.
• If you are thinking about moving to a new host instead of upgrading, plan it properly first. Our website migration plan covers the steps.

Ask your host for help when:

• You cannot find the plugin, or you are not sure CloudLinux is in use.
• The snapshots show scripts or queries you do not recognise.
• Faults keep happening after you have cached, trimmed plugins and moved scheduled tasks.
• You want to know exactly what the next plan changes for the limit you keep hitting.

The one message worth forwarding

Copy this, fill in the brackets, and send it to your host's support team:

Hello,

My site [your domain] has been slow or showing errors around [day and time].

Before I decide whether to upgrade, could you please tell me:

1. Does my account run on CloudLinux with the LVE Manager resource usage plugin?
2. If yes, what is the name of that plugin in my control panel, and where do I find it?
3. What are my current limits for CPU (SPEED), physical memory (PMEM), entry processes (EP), processes (NPROC), IO and IOPS?
4. Which of these limits did my account hit during the time above, if any?
5. Would the next plan up raise the specific limit I am hitting?

Thank you.

Read the faults first, then pay for the fix that matches them.