“508 Resource Limit Is Reached”: Find and Fix the Limit

Short answer: “508 Resource Limit Is Reached” comes from CloudLinux. The account hit its EP (entry processes) limit, meaning too many PHP requests were running at the same time. Confirm the account and the time with lveinfo -d --period=2h --by-fault=any, then use the access log to find what drove the concurrency. The usual causes are bots, brute-force attempts, uncached pages, slow external calls and wp-cron. Fix that first. Raise EP (with NPROC and PMEM) only for a site that is busy for legitimate reasons.

The CloudLinux commands (lveinfo, lvectl, lvetop) were checked against the official CloudLinux documentation and knowledge base (linked below) on 6 October 2026; our lab has no CloudLinux server yet. The access-log commands were run on our cPanel lab (AlmaLinux 9.8, cPanel & WHM 11.138, EasyApache 4) on the same day. That lab has no LVE limits, so it showed no 508s, and there is no 508 sample output here.

What “508 Resource Limit Is Reached” means

On a CloudLinux server, each cPanel account runs in its own LVE with limits for CPU, memory, processes and disk IO. One of them, EP, caps how many requests can be inside the account’s LVE at once: mostly PHP/CGI requests, plus SSH and cron entries. According to the CloudLinux limits documentation, when the number of concurrent requests goes above EP, the web server serves the 508 page. The default EP is 20.

EP limits concurrency, not traffic. A site can handle hundreds of requests per second if each takes 50 ms. The same site hits the limit at about 10 requests per second if each request takes 2 seconds (20 slots, each busy for 2 s). So slow requests cause 508s just as much as heavy traffic does. That is why “raise EP” is often the wrong first move.

Other limits produce different symptoms. Memory (PMEM) and process (NPROC) faults usually show as 500 or 503 errors, and CPU or IO limits make the site slow without an error. The CloudLinux limits documentation (linked below) describes each one, and our CloudLinux 10 CageFS and LVE notes cover the cPanel side.

Confirm which account and which limit

Start on the server, not in the browser. lveinfo reads the lve-stats history. This command is from CloudLinux’s own 508 troubleshooting article. It lists accounts with any fault in the last 2 hours and shows only the fault columns:

lveinfo -d --period=2h --by-fault=any --show-columns="ID,CPUf,EPf,PMemF,NprocF,IOf,IOPSf"

-d converts LVE IDs to usernames. A high EPf confirms the 508s came from that account. If PMemF or NprocF is also climbing, the account is short on memory or processes too. Then look at one account over a longer period:

lveinfo --period=1d --user=bob
lveinfo -d --period=1d --by-fault=ep

In WHM, CloudLinux Manager shows the same per-user history with graphs, which is useful to show a customer. For a live view during an incident, run lvetop.

Find what is using the entry processes

EP faults tell you when and who, and the access log tells you why. On cPanel with EasyApache 4 the per-domain logs are in /etc/apache2/logs/domlogs/ (also reachable as /usr/local/apache/domlogs): one file for HTTP and one ending in -ssl_log for HTTPS. In the default combined format, field 1 is the client IP, field 4 the time, field 7 the URL and field 9 the status code.

L=/etc/apache2/logs/domlogs/example.com-ssl_log

# how many 508s per minute (shows when the spikes were)
awk '$9==508 {split($4,t,":"); print t[1]":"t[2]":"t[3]}' $L | sort | uniq -c | tail -20

# status code totals
awk '{print $9}' $L | sort | uniq -c | sort -rn

# top client IPs and top URLs during the problem window (adjust the date/hour)
grep '06/Oct/2026:14' $L | awk '{print $1}' | sort | uniq -c | sort -rn | head
grep '06/Oct/2026:14' $L | awk '{print $7}' | sort | uniq -c | sort -rn | head

We ran the status-code and top-URL commands on our lab’s domlogs to confirm the field positions. Even on a brand-new test site, the top URLs included scanner probes such as /.git/config and /.env.production. Bots arrive within hours.

What the results usually point to:

What you see	Likely cause	Fix
Hundreds of POSTs to /wp-login.php or /xmlrpc.php from a few IPs	Brute-force attack	Block at the firewall/WAF, rate-limit, disable XML-RPC if unused
One crawler or AI bot user agent fetching many pages	Aggressive crawler	Block or throttle it, and serve it cached pages
Many /wp-admin/admin-ajax.php requests	Heartbeat or a plugin polling	Reduce heartbeat frequency, fix or replace the plugin
Requests to /wp-cron.php on every visit	WordPress pseudo-cron	Disable it and run cron from the system
Normal traffic, but each request is slow	Slow queries, uncached pages, external API timeouts	Page caching, query fixes, shorter timeouts
Traffic spike from a campaign or a mention	Legitimate load	Cache first, then raise limits

Fix the cause before raising limits

1. Stop abusive traffic. Block brute-force IPs and bad bots at the firewall or WAF so they never start a PHP process. On Imunify360 servers, Under Attack Mode and the L7 rate limiter exist for exactly this.
2. Cache. A full-page cache answers anonymous visitors without PHP, so those requests stop counting against EP. On LiteSpeed, see LiteSpeed Cache for WordPress on cPanel.
3. Move WordPress cron to the system. Add define('DISABLE_WP_CRON', true); to wp-config.php. Then add a cPanel cron job that runs wp cron event run --due-now (WP-CLI) every 5 to 15 minutes. On our cPanel lab, WP-CLI only worked when called through an EA-PHP CLI binary, for example /opt/cpanel/ea-php83/root/usr/bin/php /usr/local/bin/wp --path=/home/bob/public_html cron event run --due-now. Use the PHP version the site uses.
4. Shorten slow requests. Find slow PHP with the PHP-FPM slow log (our PHP-FPM Slow Log Analyzer script helps). Add timeouts to outgoing HTTP calls in plugins, and fix the heavy database queries.
5. Check for compromise. A sudden constant load from POSTs to odd PHP files in wp-content/uploads is a sign of a backdoor, not of popularity.

When and how to raise EP

Raise the limit when the traffic is legitimate, the pages are already cached and the 508s continue. Raise related limits together:

• EP for more concurrent requests.
• NPROC so it stays well above EP. NPROC counts every process and thread in the LVE, including the ones EP lets in.
• PMEM for roughly EP multiplied by the memory each PHP request uses at peak, or the extra requests just turn into memory faults (500/503).
• PHP-FPM max children for the domain, so PHP can actually use the extra slots (see cPanel PHP-FPM tuning).

In WHM, open CloudLinux Manager, go to Users (one account) or Packages (everyone on that plan) and edit the limits. From the shell, the command form from cPanel’s knowledge base is:

lvectl set-user bob --maxEntryProcs 40 save

Prefer changing the package if many accounts on the same plan show EP faults, because per-user overrides are easy to forget. CloudLinux’s published “high-end” profile uses EP 40 with PMEM 1 GB and SPEED 200%, against EP 20, PMEM 512 MB and SPEED 100% for a typical account.

Raising EP on a server that is already short of CPU or RAM just moves the problem: every account slows down instead of one returning 508. Check the server’s total load before you raise limits for many accounts.

Check that it worked

lveinfo --period=1h --user=bob                 # EPf should stay at or near 0
awk '$9==508' /etc/apache2/logs/domlogs/example.com-ssl_log | tail   # no new 508 lines

Check again at the next traffic peak (often the next business day), because 508s appear at peaks.

Every site on the server shows 508

If all accounts return 508 at the same time, even quiet ones, the cause is not one busy site. CloudLinux has a knowledge-base article for exactly this case. Its checks are lvectl list (are real limits applied, or only the default?), then disabling CageFS for one affected user as a test (cagefsctl --disable bob). In that case the root cause was corrupted LVE packages, fixed by reinstalling them. Because this changes core CloudLinux packages, open a ticket with CloudLinux support before you follow that fix on a production server, and re-enable CageFS for the user afterwards.

Common problems

• EP was raised but 508s continue. PHP-FPM or LiteSpeed is still capping workers lower, or the requests are so slow that any limit fills up. Fix the slow requests.
• 508 only for logged-in users or in wp-admin. Those pages are not cached. Look at admin-ajax, heavy admin plugins and the heartbeat.
• 508 at the same minute every hour. A cron job or backup inside the account is using entry processes. Check the account’s cron jobs.
• The customer sees 508 but lveinfo shows no EP faults. Check the domain’s log for the exact time and status. A CDN or proxy in front of the site may be showing its own error page.

Official documentation: CloudLinux docs: Limits (EP and the 508 page) · CloudLinux KB: 508 Resource Limit Is Reached · cPanel KB: change LVE limits from the command line

Related: CloudLinux 10 cPanel: CageFS and LVE Limits, Upgrade Notes · cPanel PHP-FPM Tuning: Sizing pm.max_children and OPcache · High Load cPanel Server: Find the Culprit Fast (5 Tools) · LiteSpeed Cache WordPress cPanel: Recommended Settings · PHP-FPM Slow Log Analyzer

See also: CloudLinux LVE Limits Explained: SPEED, PMEM, EP, NPROC, IO · “Cannot Manage PHP Versions When CageFS Is Disabled”: PHP Selector Fix

Frequently asked questions