On services using CloudLinux, cPanel may expose resource usage and fault information for the hosting account. A fault indicates a limit was reached, which should be correlated with the affected time and workload before changing the application or plan.
IN THIS ARTICLE
Information to have ready
Confirm the feature is available on your service. Record the time of the slow request or error and note recent imports, backups, plugin changes or traffic campaigns.
01 Read CPU and concurrent connection fault information
- Open the available Resource Usage or CPU and Concurrent Connection Usage interface.
- Select a time range covering the incident and inspect which resource reached its limit. CPU, memory, I/O and concurrent-entry limits describe different constraints.
- Compare fault times with access logs and scheduled jobs. Look for repeated overlapping tasks, unusually expensive requests or a sudden traffic increase.
- Reduce the identified cause where possible, such as staggering heavy jobs, correcting a slow query or enabling suitable application caching. Change one factor at a time.
- Repeat a representative test and compare the same resource graphs. If normal legitimate demand consistently exceeds the allowance, discuss a suitable service capacity change.
02 How to interpret common resource labels
| Label | What to investigate |
|---|---|
| CPU or SPEED | Processing time used by scripts and jobs. Reaching this allowance can slow work rather than produce one specific error page. |
| PMEM | Physical memory used by the account environment. Compare the incident with memory-heavy jobs or simultaneous requests. |
| EP | Concurrent entries into the account environment, as measured by the server integration. This is not a count of unique visitors or monthly visits. |
| NPROC | The account process-count limit. Investigate accumulated workers or overlapping tasks. |
| I/O and IOPS | Storage throughput and the number of storage operations per second. These describe different limits. |
Read the actual limits shown for your service. Compare the same incident window before and after a change, and ask support to interpret an unfamiliar counter rather than treating these labels as recommended plan settings.
Confirm the expected result
The relevant fault pattern should decrease while the application still completes its work. A quiet graph outside the original incident window does not prove the underlying problem has disappeared.
Troubleshoot unexpected results
If the interface is missing, the server may use a different resource-management arrangement. Send support the timestamp, URL and symptom rather than guessing a limit. Avoid blindly killing processes or increasing application memory settings beyond the actual account allowance.
Is every slow page caused by a hosting limit?
No. External APIs, browser assets, DNS, database locks and application errors can also cause delays. Resource evidence helps narrow the cause when it aligns with the actual failure.