Error 508 · server

508 Resource Limit Is Reached

Ben Johnson · last verified 2026-08-02

Also seen as: 508 error · Resource Limit Is Reached · LVE limit reached

What it actually means

508 is not a standard HTTP status the way 404 or 500 are — it is what shared hosts return when a per-account resource limit is enforced at the kernel level.

On a shared server, every account gets a slice: some percentage of a CPU core, a memory ceiling, and a maximum number of PHP processes running at once (often called entry processes). When your site tries to exceed its slice, the host has two options: let you take down the whole server, or refuse your request. It refuses your request.

That is a critical distinction: a 508 is the server protecting itself, and it is temporary. It clears the moment your usage drops back under the ceiling — usually within seconds. Nothing is broken and nothing is suspended.

Why it happens

Traffic arrived faster than PHP could serve it

This is the most common cause by far. If your entry-process limit is 10 and each page takes 2 seconds to build, you can serve roughly 5 requests per second. The 11th simultaneous visitor gets a 508.

The fix is almost never “more resources” — it is making each request finish faster, so processes free up sooner.

A slow query or slow external API call

One unindexed database query taking 4 seconds holds a PHP process open for 4 seconds. Ten of those and every process slot is occupied. The same applies to file_get_contents() against a slow third-party API with no timeout set.

This is why 508s often appear on a site whose traffic has not changed — a table grew past the point where a missing index mattered.

Bots, not people

Scrapers, vulnerability scanners, and aggressive crawlers routinely make up the majority of requests to a small site. They hit expensive uncached pages — search results, filtered archives, calendar views — that real visitors rarely touch.

A plugin or cron job doing heavy work in-request

WordPress’s wp-cron.php runs on page load by default, so a scheduled backup or feed import executes inside a visitor’s request, consuming a process slot for the duration. Backup and image-optimisation plugins are frequent offenders.

How to fix it

1. Turn on full-page caching

The single highest-leverage change. A cached page is served as a static file and consumes no PHP process at all, so it cannot contribute to a 508.

On WordPress, install a static-file cache plugin (LiteSpeed Cache if your host runs LiteSpeed, otherwise WP Super Cache). Confirm it is actually working — many installs are configured but not caching:

curl -sI https://example.com/ | grep -i -E 'x-litespeed-cache|x-cache'

Expect to see a hit after the second request. If you never see one, the cache is not engaged and the plugin is doing nothing.

2. Find the slow query

Enable query logging and look for anything over ~200 ms. In WordPress, define('SAVEQUERIES', true); plus Query Monitor will show you the offenders directly.

Most of the time the fix is one index:

-- see what a slow query is actually doing
EXPLAIN SELECT * FROM wp_postmeta WHERE meta_key = 'my_key';

-- if it reports a full table scan, index the column
CREATE INDEX idx_meta_key ON wp_postmeta (meta_key);

3. Disable WordPress's in-request cron

Stop scheduled tasks from running inside visitor requests. In wp-config.php:

define('DISABLE_WP_CRON', true);

On a free plan with no real cron available, trigger wp-cron.php from an external scheduler (cron-job.org and similar are free) every 15 minutes instead.

4. Block the bots that are costing you processes

Check your access logs for the top user agents. If a scraper is responsible, block it in .htaccess:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (AhrefsBot|SemrushBot|DotBot|MJ12bot) [NC]
RewriteRule .* - [F,L]

Do not block Googlebot or Bingbot. Verify anything claiming to be Googlebot by reverse DNS before trusting the user agent — it is trivially spoofed.

5. Set timeouts on every outbound request

An external API with no timeout can hold a process for as long as it wants to. Always bound it:

$ctx = stream_context_create(['http' => ['timeout' => 3]]);
$body = @file_get_contents($url, false, $ctx);

Three seconds is generous for an API call. Without a timeout, PHP will wait up to default_socket_timeout — 60 seconds by default.

On CWP specifically

When this means you've outgrown free hosting

Related errors

• 500 500 Internal Server Error
  Something in your application or server configuration crashed, and the server is deliberately withholding the detail from visitors — the real message is in your error log.
• DB Error establishing a database connection
  PHP reached the point of trying to talk to MySQL and failed — because the credentials are wrong, the hostname is wrong, or the database server refused the connection.
• 502 502 Bad Gateway
  A server in front passed your request to a server behind it, and got back a broken response or none at all.
• 504 504 Gateway Timeout
  The proxy in front gave up waiting for the backend to answer — your code is running, it is just taking too long.
• TIME Maximum execution time exceeded
  A PHP script ran longer than allowed and was stopped — almost always waiting on a slow query or a slow external service.
• 1040 MySQL: Too many connections
  Your account is already holding as many database connections as it's allowed, so new requests are refused until one frees up.
• 429 429 Too Many Requests
  You sent more requests than the server allows in a given period, so it's refusing you until the window resets.