508 Resource Limit Is Reached — Find What Filled Your Account's Process Slots

"508 Resource Limit Is Reached" means your hosting account had too many requests running at the same moment, and the server refused the next one. It comes from the account isolation layer on shared hosting (CloudLinux's LVE is the common one), not from WordPress. It is a concurrency limit, so a quiet site can hit it, and a busy one can avoid it.

What the limits are

Isolation software gives each hosting account its own slice of the server, measured in several limits:

The 508 page is the entry-process limit. Your hosting panel's resource usage page shows faults per limit by time; open it and confirm that the faults are EP faults and when they happened. That timestamp is what you will match against the access log.

Concurrency is rate times duration

The number of requests running at once equals requests per second multiplied by how long each one takes. Ten requests a second at 0.2 seconds each keep two slots busy. The same ten requests at 3 seconds each need thirty, and an EP limit of 20 or 30 turns that into a stream of 508s.

That is the trap: a request that is waiting uses no CPU but still holds a slot. A plugin calling a remote API on every page load with a 30-second timeout, a slow database query, or a call to a service that is down — the CPU graph stays flat, memory looks fine, and EP sits at the ceiling. Hosts' "upgrade your plan" emails rarely mention this. If the CPU graph is quiet while EP faults pile up, look for waiting, not computing.

Find what filled the slots

Download the raw access log for the fault window and group it:

# Busiest client IPs
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head
# Busiest paths, query strings removed
awk '{print $7}' access.log | cut -d'?' -f1 | sort | uniq -c | sort -rn | head -20
# Requests per minute, to see the spike
awk '{print substr($4, 2, 17)}' access.log | uniq -c | sort -rn | head

Then match what you see:

Fixes, in order of effect

1. Serve pages without PHP. A page cache that writes static files served by the web server answers anonymous visitors without using an entry process. A cache that still boots WordPress to serve the page helps less. Speeding up WordPress covers what to cache and what cannot be cached.
2. Block bots before PHP. Rules in .htaccess (see the default .htaccess for where custom rules go) or the host's firewall reject requests without starting PHP. A WordPress security plugin blocks them only after PHP has started, usually after WordPress has loaded, so each blocked request still costs a slot.
3. Move WP-Cron to a real schedule. By default WordPress checks for due events on page loads and fires a separate HTTP request to wp-cron.php when one is due. On a busy site that adds requests exactly when slots are scarce. Disable WP-Cron and run it from the system scheduler every five minutes.
4. Shorten slow requests. Remote calls that time out show up as cURL error 28 in logs; find the plugin making them and cache its responses or replace it.
5. Calm the admin. Each open dashboard tab sends a Heartbeat request about once a minute; editors with many tabs keep slots busy all day. Speeding up the admin covers Heartbeat settings.

Common mistakes

• Reading the CPU graph, seeing headroom, and concluding the host is wrong.
• Installing a heavier security plugin to fight bots that reach PHP anyway.
• Upgrading the plan without checking which limit faulted.
• Leaving staging copies with WP-Cron running in the same account: they share its limits.

Verify

• The resource usage page shows no new EP faults for a few days of normal traffic.
• curl -sI https://example.com/ returns a cache hit header for anonymous pages, if your cache sets one.
• The access log no longer shows bot bursts reaching wp-login.php with 200 responses.
• If the site is still unreachable after this, work through site not loading from the top.