CloudLinux resource faults show that an account reached a configured limit; they do not identify the underlying cause by themselves. Read the limit, usage and fault counters for the same time interval, then correlate them with requests, application errors and scheduled work before choosing a fix.
Read the resource correctly
The CloudLinux limits reference defines these controls:
- SPEED limits CPU time relative to a core; it is not a dedicated-core allocation promise.
- PMEM limits physical memory use.
- IO limits combined read/write throughput; IOPS limits operation count.
- EP limits entry processes, not monthly visitors or total logged-in customers.
- NPROC limits processes within the account's LVE.
Use the values shown for your actual account. Vendor examples do not establish current WebCare360 plan specifications. Consult current hosting plans and your service details for commercial allocations.
Match symptoms to the interval
CPU or IO limiting can slow work. Memory or process exhaustion can cause failed requests; an EP limit can produce a 508 response in the documented integration. The exact symptom depends on the application and server stack, so do not diagnose solely from an HTTP status.
There is no universal harmless number of faults per week. A short event that interrupts checkout can matter more than many faults during a disposable batch job. Record duration, affected URLs, error rate and customer impact.
Investigate one cause at a time
- Save the Resource Usage interval and timezone, including the limit, peak and fault count.
- Compare access logs with application errors and cron or backup schedules for that interval.
- Check slow requests, database work, concurrency and cache behavior. A repeating pattern is a lead, not proof of an internal cause; irregular demand is not proof of an attack.
- Reproduce safely in staging or observe a comparable production interval.
- Make one justified change and compare results under similar demand.
Choose optimization or more capacity from evidence
Examples include staggering scheduled work, correcting an expensive query, caching eligible responses or filtering confirmed abusive traffic. Do not cache private sessions or impose broad blocking merely to lower a counter. Increasing the wrong resource may leave the bottleneck unchanged.
If legitimate sustained demand still exceeds the relevant allocation after investigation, ask about an appropriate plan or service model. Send support the timestamps, affected task and resource evidence. WebCare360 publishes this guide as a hosting provider; an upgrade recommendation should follow the measured constraint, not a fault counter alone.
If the evidence points to a different service model, compare shared hosting with VPS, including administration responsibilities. The comparison does not make a VPS the automatic answer to a resource fault.
