Performance & limits
508 Resource Limit Is Reached: entry processes and the next checks
Understand cPanel entry processes, correlate resource faults, and identify why shared-hosting requests are being rejected.
On shared hosting that uses CloudLinux, a “508 Resource Limit Is Reached” page can mean that the account has exhausted its entry-process allowance. Confirm the host’s explanation and resource logs: the status code alone does not identify every server configuration or failure.
The useful question is which limit rejected work at the time of the error. Buying more storage or deleting a few images will not necessarily change that limit.
What are cPanel entry processes?
Entry processes, often shown as EP in a hosting resource panel, concern concurrent entries into the account’s execution environment. They are not a monthly visitor count, open browser tabs, or the same thing as the total process limit.
CloudLinux’s limit documentation describes Apache requests reaching a 508 when the entry allowance is exhausted. It also explains that LiteSpeed accounts for entries differently. Do not apply a simple “EP equals simultaneous visitors” formula across hosts.
Read the whole resource picture
| Resource | Why it matters |
|---|---|
| Entry processes | Can reject new work when concurrent entries reach the configured limit. |
| CPU | Constrained processing can make requests take longer to finish. |
| Memory and process count | Separate ceilings that require their own fault evidence. |
| Disk throughput and IOPS | Storage bottlenecks can increase request duration. |
Look at faults over the incident interval rather than a quiet graph hours later. Ask whether the allowance applies to one website or the entire account. Several small sites may share the same constrained pool.
Find out why requests overlap
A burst of legitimate demand can create concurrency. So can requests that finish slowly. As an illustration, a route receiving five requests per second with each request occupying work for four seconds can have roughly twenty requests in progress. That is a workload estimate, not a conversion to a particular host’s EP counter.
Compare access logs, slow requests, scheduled jobs, and resource faults at the same timestamps. Repeated searches, uncached pages, slow database operations, and external API waits are possible leads. Verify one before changing the application.
The WordPress monitoring guide identifies profiling as a way to locate costly operations. If you cannot profile the account, ask support for the affected process or URL rather than accepting only a screenshot of the limit.
Reduce unnecessary work safely
Cache suitable public pages, fix the expensive operation, and avoid overlapping bulk tasks. Keep customer-specific pages and checkout outside inappropriate caching. If abusive requests are confirmed, apply a targeted restriction and check legitimate use afterward.
Do not delete application files or kill unfamiliar processes simply because they are running. Preserve a recoverable state and investigate component changes on a separate copy when possible. Our high CPU guide provides a related evidence workflow.
Know when an upgrade helps
An upgrade helps when it increases the limit that normal workload genuinely needs. Get the new EP, CPU, memory, and I/O allocations in writing, including whether the values are shared across your sites. A package described only as “more powerful” is difficult to evaluate.
Provide support with the URL, timestamp and timezone, error screenshot, frequency, and business impact. Ask which fault counter changed and what happens at the ceiling. After a fix or upgrade, compare error frequency and response time over a similar traffic window. The objective is reliable requests, not merely a larger advertised allowance.