CloudLinux places each shared-hosting account inside a Lightweight Virtual Environment so one customer cannot consume the entire server. When an account reaches a limit, requests may slow down, return 503 or 508 errors, or fail to start. The fault type tells you what to investigate.
CPU Limit
CPU is usually shown as a percentage or number of cores. When the account reaches it, work is throttled rather than necessarily killed. Pages become slow and PHP queues can grow. Identify expensive URLs, uncached traffic, cron jobs, malware scans, backups, and database queries at the same timestamp.
Physical Memory
Physical memory is the total RAM used by the account’s processes, not the same as the PHP memory_limit for one script. A fault can terminate a process and produce an error. Look for concurrent PHP workers, image processing, import jobs, command-line tasks, and processes that grow without releasing memory.
I/O and IOPS
I/O limits disk throughput; IOPS limits the number of operations. Backups, malware scans, cache rebuilds, large logs, imports, and database-heavy work can saturate storage. The site may feel slow even with low CPU. Schedule heavy jobs apart and avoid generating multiple full backups at once.
Entry Processes
Entry processes represent concurrent requests entering the account, not total visitors. Slow uncached PHP requests remain active longer and consume slots. A burst of bots, slow external API calls, or stuck database queries can exhaust the limit. Page caching and faster request completion often help more than blocking one IP.
Number of Processes and Inodes
The process limit includes active account processes such as PHP, cron, and shell tasks. Inodes count files and directories. Large cache trees, sessions, email, backups, and millions of small files can hit inode limits even when disk space remains. Delete only identified, recoverable data after a backup.
Read the Fault Timeline
Open cPanel Resource Usage and compare faults with uptime alerts, access logs, cron schedules, deployments, and traffic. A current dashboard after the event may look normal. Export screenshots or data with the host’s time zone and record the affected URL.
For WordPress outages, use our 503 recovery workflow. For general performance, see speeding up WordPress on shared hosting.
Fix Before Upgrading
- Verify page caching for anonymous pages.
- Find the request, process, or schedule matching faults.
- Remove malicious or abandoned tasks.
- Optimize measured slow queries and external calls.
- Spread backups, scans, and imports across time.
- Upgrade when legitimate sustained load still exceeds the plan.
Recheck the same LVE graphs after each change. Moving a backup job may eliminate I/O faults while leaving entry-process faults untouched, which is useful evidence rather than a failed optimization. Keep each intervention separate enough to measure.
Frequently Asked Questions
Does one CPU fault mean the plan is too small?
No. A deployment, scan, attack, or runaway task can cause a brief fault. Look for frequency, duration, and legitimate demand.
Is PHP memory the same as physical memory?
No. PHP memory limits one script; CloudLinux physical memory covers the account’s concurrent processes.
Why do I see 503 only during traffic bursts?
Entry processes, CPU, memory, or PHP workers may be exhausted. Correlate the exact burst with LVE and access logs.
Final Decision
Use the specific fault and timestamp to choose a fix. Optimize waste when evidence shows waste; buy more capacity when real, efficient demand is sustained. A generic upgrade without diagnosis can preserve the same failure at a higher price.
