Skip to main content
Resource Usage is CloudLinux’s LVE Manager view of your account. It tells you, hour by hour, whether your account is hitting its CPU, RAM, I/O, or process caps. When the site feels slow or returns 508s and you don’t know why, this is the page you open. The data comes from the kernel-level isolation layer that runs on every Noxity server (LVE), not from cPanel itself. cPanel just embeds the LVE Manager UI as a tab.
Resource Usage Dashboard tab with limit warning

​
The four tabs

TabAnswers the question
DashboardHave I hit any limit in the last 24 hours?
Current usageWhat is my account using right this second?
SnapshotWhat was usage like at any past hour?
OptionsHow and when do I want to be notified about limit hits?

​
Dashboard

The first tab you land on. Two outcomes:
  • All clear. The page reads “Your account is using less than…” with no warnings.
  • Limit reached. The header switches to You have reached the limits within the past 24 hours and a list of the affected resources appears below it. A Details button drops you on the Snapshot tab pre-filtered to that resource and time range.
Dashboard showing CPU resources limit was reached
The bullet list aggregates faults across the 24-hour window. To see exactly which hour something happened, click Details or jump to the Snapshot tab.

​
Current usage

A live point-in-time view. Refresh the page and the numbers update.
Current usage table with rows for SPEED, I/O, IOPS, NPROC, EP, PMEM, Inodes
Four columns:
ColumnMeans
DescriptionThe resource being measured.
UsageWhat the account is using right now.
LimitThe cap set by the plan.
FaultHow many times this resource has been throttled in the current accounting interval. 0 is healthy; non-zero means active throttling.

​
What each row tracks

RowTracksExample value
SPEED UsageCPU as a percentage of one core. 100% = one full core; 200% = two cores fully used.200% (2 cores)
I/O UsageDisk read+write throughput, in MB/s.30 MB/s
IOPSDisk read+write operations per second. Independent of MB/s.1024
NPROCTotal OS-level processes owned by the account. Every fork counts (cron, PHP-FPM children, SSH sessions, mail daemons).150
Entry ProcessesConcurrent web requests being executed. Different from NPROC: only counts inbound HTTP requests in flight.60
Physical Memory UsageRAM actually in use. Hard cap; over-cap requests get killed.4 GB
Inodes usageFiles on disk. One file = one inode, regardless of size.250,000
The “Example value” column shows representative numbers from one of our entry-tier plans. Your actual caps depend on the plan and the server you’re on, and some plans push every value higher. Check the Limit column on your own Current usage tab for what’s set on your account.

​
What a Fault means in practice

Fault countWhat’s happening
0The resource is below the cap. Nothing throttled.
1–5 per hourBackground noise. Likely a single brief spike (a cron, a one-off slow request).
Tens per hourSomething specific is hot. Investigate via Snapshot.
Hundreds per hourSustained throttling. Either a runaway process, an attack, or you’ve outgrown the plan tier.
When SPEED hits its limit, requests get queued for a few ms and visitors see slower pages. When EP hits its limit, additional requests get a 508 immediately. When PMEM hits its limit, the offending process gets killed by the kernel.

​
Snapshot

The most useful tab when you’re debugging “the site was slow at 3pm yesterday.” A row per hour, going back several days.
Snapshot table with From/To and SPEED, PMEM, IO, EP, NPROC, IOPS columns
Each row covers one hour, identified by From and To timestamps. Across the columns are six resource groups:
GroupWhat it is
SPEEDCPU
PMEMPhysical memory
IODisk throughput in MB/s
EPEntry processes (concurrent HTTP requests)
NPROCTotal processes
IOPSDisk operations per second
Each group has three sub-columns:
Sub-columnMeans
AAverage usage during that hour
LLimit during that hour (only changes when your plan changes)
FFaults: count of throttling events in that hour

​
Reading the table

A worked example using one of the rows from the screenshot:
Row 27-04 05:00 → 27-04 06:00: SPEED 8% / 200% / 0, PMEM 32.09M / 4G / 0, IO 26.52KB/s / 30MB/s / 0, EP 1 / 60 / 0, NPROC 2 / 150 / 0, IOPS 1 / 1024 / 0.
Read it like this:
  • CPU averaged 8% of the 200% cap. No throttling.
  • RAM averaged 32 MB out of 4 GB. Not close.
  • Disk throughput averaged 26 KB/s, well under the 30 MB/s cap.
  • One concurrent web request on average. Two background processes. One disk operation per second.
That’s a typical idle hour for a low-traffic site. A more interesting row would have a non-zero F somewhere. That points at the exact hour the resource was hit. Cross-reference with your application logs (or the Errors tool) for the same time window.

​
IO vs IOPS

Two separate caps. A file workload can blow through one without touching the other:
WorkloadHigh in IOHigh in IOPS
Sequential read of one large file (a 2 GB video stream)YesNo
Random reads against thousands of small files (a find over node_modules, mail spool scan)NoYes
WordPress page render with many uncached queriesMild on bothMild on both
If both are low and the site is still slow, the bottleneck is somewhere else, usually SPEED or EP.

​
Period switcher

Above the table, a Period dropdown switches between Hourly, Daily, and Monthly aggregates. Hourly is the default and the most useful for incident debugging. Monthly is useful for capacity planning (“am I trending toward the cap?”).

​
Options

Notification settings. The page lets you tick which channels to use when a fault happens, plus thresholds for when to send. The defaults are sensible:
  • Email when a resource hits 100% (a fault).
  • Don’t email more than once per hour per resource.
  • Don’t email below 80% (warning threshold).
You can tighten the warning threshold or disable notifications entirely. We don’t recommend disabling them. When something starts melting, the email is usually the first signal.
Email goes to the contact email on your cPanel account, not necessarily the one you log in with. Check Contact Information in the cPanel home if your alerts aren’t reaching the right inbox.

​
Common questions

NPROC counts every process running under the account: PHP-FPM children, cron jobs, SSH sessions, mail daemons, your own scripts. EP counts only concurrent inbound web requests being executed by Apache or LiteSpeed. EP usually has the lower limit because it’s the user-facing one. When EP fills up, new requests get 508s; when NPROC fills up, new forks fail (which can manifest as cron jobs not running or PHP failing to spawn workers).
No. SPEED is reported as a percentage of one CPU core. 200% means two full cores. The limit is also expressed the same way. If your plan caps you at 2 cores, the limit shows as 200%. A row reading SPEED 200% / 200% / X means you used the full allocation; the F column tells you whether you also tried to exceed it.
Yes. Once you hit the cap on your plan, you can’t create new files until you delete some. Mail messages, session files, cache files, npm packages, and tiny WordPress media all count. See Email Disk Usage for one common offender; large mailboxes can hold hundreds of thousands of inodes.
A small number of faults (a handful per day) is normal background noise from cron jobs and brief request spikes. Hundreds in an hour means something specific is wrong: a runaway script, a scraper hammering the site, or a misconfigured plugin. Sustained faults week over week mean the account has outgrown the current plan tier.
LVE history is kept for a rolling window that varies by plan and server. Anything outside the window is gone. If you need older data for a post-mortem, open a ticket with the date range. We may have it server-side.
Plan-level limits aren’t user-adjustable. They’re set per tier. The 4G is the cap, not a reservation; you only use what you actually allocate. If you’re sitting at 200 MB, you’re using 200 MB.

​
Need a hand?