# 508 Resource Limit Is Reached

> Your account hit its CPU, memory, or concurrent-process ceiling, so the server refused the request instead of letting your site destabilise the machine.

Source: https://cwp.sg/errors/508-resource-limit-is-reached/  
Author: Ben Johnson  
Last verified: 2026-08-02

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

## What it 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:

```sql
-- 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`:

```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`:

```apache
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:

```php
$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 hosting specifically

CWP free accounts are limited to 25% of one CPU core, 256 MB of memory, and 10 concurrent entry processes. You can see live usage — including exactly when you hit a limit — on the **Resource Usage** page of your control panel.

We deliberately show you the graph rather than only the error, because in our experience most 508s are fixed by the site owner within a day of being able to see the spike. If your graph shows a flat line with brief vertical spikes, you have a burst problem (caching fixes it). If it shows a sustained plateau at the ceiling, you have a capacity problem (see below).

## When this means you have outgrown free hosting

If you are hitting 508s **after** enabling caching, fixing slow queries, and blocking bad bots, then the honest answer is that your site now needs more than a free shared account can give it — and no configuration change will alter that.

A sustained plateau against the process limit means real, concurrent, dynamic traffic. That is a good problem. At that point a paid plan with a higher process ceiling, or a small VPS if you are comfortable with server administration, is the correct move.

---

Content Website Platform (cwp.sg) operates the free hosting it writes about; see https://cwp.sg/about/ for the methodology and the commercial disclosure.