Reading your cPanel resource usage: EP, NPROC and IOPS

This picks up from a cPanel account you can log in to. The “CPU and Concurrent Connection Usage” page in cPanel is CloudLinux’s Resource Usage plugin. EP is concurrent web entries, NPROC is total processes, IOPS is disk operations per second. Hitting EP shows HTTP 508. CPU, IO and IOPS usually slow you down instead. Use the Faults counters and Snapshot to decide if you need more capacity or if one script is misbehaving.

Before you start

The cPanel screen you are about to use only appears on servers that run CloudLinux. cPanel’s own docs say so. If you do not see “CPU and Concurrent Connection Usage” under Metrics in cPanel, open a browser tab and open a support ticket. We will confirm what is available on your plan and point you at the right place.

• The Resource Usage interface is read-only. You cannot break anything by opening it, changing the timeframe or viewing the Snapshot.
• CloudLinux defines the limits you see: SPEED (CPU, shown as a percentage of a single core), PMEM (physical memory), IO (disk throughput in KB/s), IOPS (disk operations per second), NPROC (number of processes), and EP (entry processes). You might not see VMEM. It is deprecated and modern panels usually expose PMEM instead.
• 508 errors mean your account hit a limit. CloudLinux ties 508 specifically to EP exhaustion. cPanel’s support material also uses 508 as a general “over the limits” sign. In practice: EP faults are the usual cause of a 508 page. PMEM or NPROC faults tend to look like 500 or 503 errors. CPU, IO and IOPS usually throttle the account and cause slow responses rather than 5xx errors.
• 100% CPU in this screen means 100% of one CPU core. It does not mean the whole server is at 100%.
• 508 on your site does not mean Hostworld’s server is down. CloudLinux isolates each account so other sites keep running.

Step 1: Open Resource Usage in cPanel

Log in to cPanel for the account that runs the site. Find the Metrics section and open “CPU and Concurrent Connection Usage”. If you cannot find it, open a support ticket and we will check whether CloudLinux metrics are enabled for you.

Step 2: Check the overview for recent limits

At the top, you will see an overview that tells you if your site was limited in the selected window and which resource caused it. Set the time range to capture your busy period. Start with 24 hours so you do not miss a lunchtime spike.

• If it says your site was not limited, you have headroom. High usage without faults means CloudLinux throttled you a little or you had brief peaks that did not hit the wall.
• If it says your site was limited, note the resource name. That is your first lead.

Step 3: Learn what each number means

Use this as your plain-English key to the columns and graphs.

• EP (Entry Processes): Counts concurrent requests entering your account through the web server into dynamic scripts such as PHP. It also counts your SSH sessions and cron jobs. It does not go up for child processes spawned by one PHP request. When EP reaches its cap, new entries are blocked and visitors see an HTTP 508 “Resource Limit Is Reached”.
• NPROC (Number of Processes): Caps how many processes and threads can run inside your account. At the cap, nothing new can spawn until something exits. On LiteSpeed this often shows up as 503 “Service Unavailable” rather than 508. A loop that creates many short-lived processes can exhaust NPROC without any EP fault.
• SPEED (CPU): Your CPU allowance as a percentage of one core. 100% is roughly one full core. At the limit, CloudLinux throttles execution. Pages take longer but do not usually throw 5xx by themselves.
• PMEM (Physical Memory): The real memory your processes use. If you exceed PMEM, CloudLinux first tries to drop caches. If that is not enough it kills processes and increments the memory fault counter. The affected requests often fail with 500 or 503.
• IO (I/O Throughput): Disk read and write speed in KB/s. Hitting IO causes throttling. Disk work slows down. Queries take longer. You do not normally get 5xx just from IO.
• IOPS: Number of disk operations per second. This is separate from IO. You can avoid the IO limit but still hit IOPS if you do lots of tiny reads and writes. The effect is slowness rather than a 5xx error.

Common confusions to avoid:

• EP is entries, not total processes. A single PHP request can spawn children without increasing EP. That is why EP and NPROC can diverge.
• IO is throughput, IOPS is how many operations. Many small ops can max IOPS without much change in the IO graph.
• CPU 100% is not the whole server. It is your slice relative to one core.

Step 4: Map limits to symptoms so you know what you are chasing

• 508 “Resource Limit Is Reached”: Most often EP is at its cap. Check EP faults first. It can also appear as a generic over-limit message in some setups, but EP is the usual culprit.
• 500 or 503 errors without 508: Check PMEM and NPROC faults. PMEM overrun kills processes, causing 500 or 503. NPROC exhaustion, especially on LiteSpeed, often shows as 503 with no EP fault.
• Site feels slow, no 5xx: Look at CPU, IO and IOPS graphs. Throttling here stretches response times. If the “Faults” column is zero for these, it was transient load and you still had some headroom.

Step 5: Use Current Usage and graphs to separate spikes from capacity problems

Switch to the “Current usage” or the equivalent view that shows per-resource “Usage, Limit, Faults” along with historical charts.

1. Look at Faults, not only percentages. Percentages tell you how busy you were. Faults mean you hit a hard ceiling. Repeated faults are evidence you are out of room. High percentages with zero faults usually mean you are busy but not limited.
2. Match times to traffic. Use the time selector to include your peak hour. If faults cluster with real traffic, that is capacity pressure. If faults appear at quiet times, suspect a cron job or a loop.
3. Zoom out before you decide. Check a full day. Then check a week. One lunchtime spike is different to daily saturation.
4. Note which resource faults first. EP faults with no CPU or memory faults point to bursts of many small dynamic hits. PMEM faults with low CPU often point to a few heavy processes, not a stampede.

Step 6: Use the Snapshot to see what was running when it broke

Open the Snapshot tab. CloudLinux takes snapshots shortly after a fault. You will see process lists and, in cPanel, database and HTTP queries captured around the time of the limit breach. This is the quickest way to move from “numbers” to “the exact script or URL”.

1. Scan HTTP queries. Look for repeating URLs. For example, many hits to a slow dynamic page will push EP up even if each request uses little CPU.
2. Check database queries. One slow or repeating query can hold PHP workers and inflate PMEM or push IO/IOPS.
3. Correlate with Faults. Pick a snapshot taken near a spike in the graphs. If you only see one heavy process around PMEM faults, you have an inefficient script. If you see many concurrent web entries around EP faults, you have a concurrency problem.

If the Snapshot tab is empty or there is nothing recent, reproduce the issue by loading the slow page a few times, then refresh the Snapshot. Do not load test during your real peak window unless you are ready to watch and back out quickly.

Step 7: Test a change safely, then roll it back if it is worse

You do not need to change server settings to learn something useful. Start with one controlled change, observe the graphs and Snapshot, then undo your change if performance worsens.

• Quick test: Change the time range to the last 30 minutes. Exercise the slow page a few times, then watch CPU, IO and EP. Undo: Set the time range back to 24 hours so you do not miss later faults.
• Application toggle: If you believe one plugin or module is heavy, disable it for ten minutes while you watch Resource Usage. Undo: Re-enable the plugin. If the change helped, you have a target to optimise or replace. If it did not, revert and keep looking. Record what you changed so you can back out cleanly.

If you are not confident making changes, skip this step and move straight to the ticket step below. Tell us what you observed in Steps 4 to 6.

Step 8: Decide on the response

Now you know which resource limits and when. Work through these options in order.

• If EP is faulting: Reduce concurrent dynamic hits. Cache more pages, reduce scraping or aggressive crawlers, and fix slow URLs identified in Snapshot. If you cannot change the application, you will need more concurrency headroom.
• If NPROC is faulting: Look for loops or a burst of short-lived processes. The Snapshot and your web logs will show repeated script entries. This often presents as 503 on LiteSpeed with no EP fault.
• If PMEM is faulting: Audit memory-hungry scripts. Large image manipulation or big queries can push memory over the cap and kill processes. Reduce per-request memory use or run fewer heavy tasks at once.
• If CPU, IO or IOPS are faulting: Optimise the heavy code paths and database queries you saw in Snapshot, or reduce how often they run. These limits throttle, so the site feels slow before anything errors.

Bring your notes and screenshots and open a support ticket if you want us to confirm what you are seeing. Include:

• Which resource faulted and when.
• Time range screenshots of the graphs with Faults visible.
• Snapshot entries that look suspicious, including URLs or queries.

If you have outgrown shared hosting and need guaranteed resources, move to a VPS where you control CPU and memory for your site alone. See our Linux VPS and browse our VPS guides to plan the move.

What next

• If you keep hitting limits and want a second pair of eyes, open a support ticket. Say which resource is faulting and paste a recent Snapshot excerpt. We will check server logs against your timings.
• If you decide to migrate to your own resources, compare plans on our Linux VPS page, then follow our VPS guides for setup and migration.