> ## Documentation Index
> Fetch the complete documentation index at: https://help.noxity.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Resource Usage
> Read CloudLinux LVE Manager: Dashboard, Current usage, Snapshot, and Options. Make sense of the SPEED, PMEM, IO, EP, NPROC, IOPS columns and what a Fault means.
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.
Limits and retention values on this page reflect default plan tiers. Higher tiers may extend them. See your plan in the [Members Area](https://members.noxity.io) for the exact numbers on your account.
## The four tabs
| Tab | Answers the question |
| ----------------- | ------------------------------------------------------- |
| **Dashboard** | Have I hit any limit in the last 24 hours? |
| **Current usage** | What is my account using right this second? |
| **Snapshot** | What was usage like at any past hour? |
| **Options** | How 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.
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.
Four columns:
| Column | Means |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Description** | The resource being measured. |
| **Usage** | What the account is using right now. |
| **Limit** | The cap set by the plan. |
| **Fault** | How many times this resource has been throttled in the current accounting interval. `0` is healthy; non-zero means active throttling. |
### What each row tracks
| Row | Tracks | Example value |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------- | -------------- |
| **SPEED Usage** | CPU as a percentage of one core. 100% = one full core; 200% = two cores fully used. | 200% (2 cores) |
| **I/O Usage** | Disk read+write throughput, in MB/s. | 30 MB/s |
| **IOPS** | Disk read+write operations per second. Independent of MB/s. | 1024 |
| **NPROC** | Total OS-level processes owned by the account. Every fork counts (cron, PHP-FPM children, SSH sessions, mail daemons). | 150 |
| **Entry Processes** | Concurrent web requests being executed. Different from NPROC: only counts inbound HTTP requests in flight. | 60 |
| **Physical Memory Usage** | RAM actually in use. Hard cap; over-cap requests get killed. | 4 GB |
| **Inodes usage** | Files 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 count | What's happening |
| ----------------- | -------------------------------------------------------------------------------------------- |
| `0` | The resource is below the cap. Nothing throttled. |
| `1`–`5` per hour | Background noise. Likely a single brief spike (a cron, a one-off slow request). |
| Tens per hour | Something specific is hot. Investigate via Snapshot. |
| Hundreds per hour | Sustained 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.
Each row covers one hour, identified by **From** and **To** timestamps. Across the columns are six resource groups:
| Group | What it is |
| --------- | ------------------------------------------ |
| **SPEED** | CPU |
| **PMEM** | Physical memory |
| **IO** | Disk throughput in MB/s |
| **EP** | Entry processes (concurrent HTTP requests) |
| **NPROC** | Total processes |
| **IOPS** | Disk operations per second |
Each group has three sub-columns:
| Sub-column | Means |
| ---------- | ---------------------------------------------------------------- |
| **A** | **Average** usage during that hour |
| **L** | **Limit** during that hour (only changes when your plan changes) |
| **F** | **Faults**: 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](/web-hosting/cpanel/metrics-analytics/errors) tool) for the same time window.
### IO vs IOPS
Two separate caps. A file workload can blow through one without touching the other:
| Workload | High in IO | High in IOPS |
| --------------------------------------------------------------------------------------------- | ------------ | ------------ |
| Sequential read of one large file (a 2 GB video stream) | Yes | No |
| Random reads against thousands of small files (a `find` over `node_modules`, mail spool scan) | No | Yes |
| WordPress page render with many uncached queries | Mild on both | Mild 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](/web-hosting/cpanel/email-management/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?
Best for anything that needs an account check or a config change on our end.
Faster for quick questions during business hours.