When a visitor sees "508 Resource Limit Is Reached", your hosting account has used more than its allotted share of the server and the host has stepped in. cPanel describes the message as the account exceeding its assigned resource limit and being temporarily unable to service the request. The fix is always one of two things: make the site use less, or give it more room. This guide shows how to tell which one you need, step by step.
TL;DR
- The 508 error means your account hit a cap on CPU, memory, disk I/O, processes or concurrent connections. It is a limit on your plan, not a crash of the whole server.
- The cause is not always traffic. Bots, heavy plugins, imports, backups and security scans can all trigger it.
- Open cPanel's Resource Usage page first, then check your access and error logs for the same minute.
- Fix the cause (block abusive bots, cache pages, remove a heavy plugin). If the site is healthy and still hits the cap, move to a bigger plan.
- Repeated 508s on a growing site usually mean it has outgrown shared hosting.
Table of Contents
- What the 508 error actually means
- The limits behind the message
- What usually causes it
- Step 1: Find out what happened and when
- Step 2: Reduce what the site uses
- Step 3: Raise the limits, or move
- Our perspective
- Stopping it from coming back
- When a bigger plan is the right answer
- FAQ
- Sources
What the 508 error actually means
Shared hosting puts many accounts on one server. To stop one busy site from slowing everyone else down, most hosts use CloudLinux, which gives each account its own isolated box with fixed limits, called an LVE. CloudLinux documents limits on CPU, memory, I/O, the number of processes, and the number of entry processes, which are essentially concurrent connections to the web server.
The 508 page is what visitors see when the concurrent-connection cap is hit. CloudLinux explains that when the entry-process limit is reached, the server returns error 508 so that a very heavy site slows down without affecting its neighbors.
The other limits behave a little differently. According to the same CloudLinux documentation, a site held back by CPU or I/O responds slowly, while one that runs out of memory or processes can return 500 or 503 errors. So a slow site, a 503 and a 508 can all be the same underlying problem wearing different faces.
The exact wording varies by host: "Resource Limit Reached", "The website is temporarily unable to service your request as it exceeded resource limit", or just a plain 508. They all point to the same place.
Is it the same as "Worker exceeded resource limits"?
No, though the name is similar. That message belongs to Cloudflare. Cloudflare's Error 1102 means a Worker, a piece of code running on Cloudflare's network, went over its CPU-time or memory limit. If you do not run Cloudflare Workers, you will not see it, and the steps in this guide do not apply. If you do, Cloudflare recommends profiling CPU use and checking Workers Logs to find the expensive code.
The limits behind the message
You do not need to memorize these, but knowing the vocabulary makes cPanel's graphs readable.
| Limit | What it measures | What it looks like when hit |
|---|---|---|
| CPU | Processor time your account uses | Slow pages, then errors |
| Memory (physical) | RAM your PHP processes hold | 500 or 503 errors, failed scripts |
| I/O | Disk read and write speed | Sluggish admin, slow backups |
| EP (entry processes) | Simultaneous requests entering PHP | 508 error |
| NPROC | Total processes and threads | 500 or 503 errors |
The table follows CloudLinux's definitions. The exact numbers differ from host to host and plan to plan, so look at your own plan details rather than trusting a generic figure.
What usually causes it
The obvious guess is "too many visitors", and sometimes that is right. But cPanel's own list of causes is broader:
- large inbound or outbound traffic
- a poorly optimized site combined with more traffic and more concurrent page requests
- demanding imports or exports
- web crawlers sending many requests per second
In practice, these are the patterns we see most on WordPress sites.
Uncached pages. Every visit runs PHP and database queries. Fifty simultaneous visitors on an uncached page means fifty simultaneous PHP processes, and entry processes run out quickly.
Aggressive bots. Scrapers, vulnerability scanners and brute-force login attempts hit wp-login.php and xmlrpc.php over and over. They look like traffic in the logs but never buy anything.
Heavy plugins. Page builders, related-post widgets, backup plugins and security scanners all consume memory and CPU. A Wordfence support reply on WordPress.org notes that combined plugin memory use can breach shared-hosting limits and that intensive scans can cause trouble on some configurations. That is not a reason to skip security, just to schedule scans sensibly and, if needed, ask your host about the right settings.
Scheduled jobs piling up. WordPress cron, a backup, an image-optimization batch and a newsletter send landing in the same minute can push you over the cap even when visitors are few. One WordPress.org troubleshooting thread describes exactly that kind of puzzle: rising entry processes and memory with broadly stable traffic. Participants suggested disabling plugins one at a time to find the offender.
A bloated database. Years of revisions, expired transients and autoloaded options make every query slower, which keeps PHP processes alive longer and stacks them up.
Step 1: Find out what happened and when
Do this before changing anything. Guessing is how people end up uninstalling the wrong plugin.
Check Resource Usage in cPanel
Log in to cPanel and open Resource Usage (on some hosts it is under Metrics). It graphs CPU, memory, entry processes, I/O and NPROC over time and shows the points where you touched a limit. Note the time of each spike. If your host shows a table of recent faults, the column with the highest fault count tells you which limit is the bottleneck.
Two useful questions to ask the graph:
- Is it one limit or several? If only entry processes spike, you have too many simultaneous requests, often from bots or uncached pages. If memory and CPU climb together, something is running heavy code.
- Is it a single spike or constant pressure? A one-off spike points to a job, import or bot burst. A steady climb points to a site that has outgrown its plan.
Read the logs for the same minute
In cPanel, open Metrics > Raw Access or the Errors page, and look at the exact timestamp of the spike. You are looking for:
- one IP address or user agent making hundreds of requests
- repeated hits to
wp-login.php,xmlrpc.php,wp-cron.phpor a search URL - requests with endless query strings (filters, calendars,
?s=searches) - PHP fatal errors or memory errors in the error log
If your server runs LiteSpeed, check for process-limit messages too. cPanel's LiteSpeed guide says a site can become slow or fail to load when it reaches the max-children process limit, and the log can show "Reached max children process limit" along with current and busy process counts. If you see that line on a shared plan, your host controls that setting, so send the log excerpt to support.
Step 2: Reduce what the site uses
If the logs show a cause, fix it. These are in order of how often they work.
Turn on full-page caching
Caching serves a saved copy of the page instead of running PHP for every visit. It is the single biggest lever against entry-process and CPU limits, because cached requests barely touch your quota. Use the caching your host provides if it has one built in; on LiteSpeed servers that is typically the LiteSpeed Cache plugin. If you want to compare approaches, this overview of caching plugin options is a useful starting point for understanding what a cache should and should not do. Always exclude cart, checkout and account pages from the cache.
We cover the broader checklist in why a WordPress site is slow on shared hosting, and the quick wins are in fix a slow WordPress site.
Block the traffic you do not want
If one IP range or bot dominates your logs, block it with your host's tools, .htaccess rules or a firewall. Login hammering is the classic case: protecting the login page keeps those requests from ever reaching PHP. Our guide to protecting the WordPress login covers edge blocking and safe recovery if you lock yourself out. Do not block search engine crawlers by accident; if a legitimate crawler is too aggressive, slow it down rather than banning it.
Find the heavy plugin
If the spikes line up with no visible traffic, test plugins. On a staging copy, or briefly on the live site during a quiet hour, deactivate plugins one at a time and watch Resource Usage. Look first at backup, security scanning, statistics, related-posts and page-builder add-ons. Replace the worst offender with a lighter option or change its schedule to off-peak.
A scan that reads every file is exactly the kind of job that eats I/O. For a lighter approach, see our two-step malware scanning for shared hosting.
Trim the database and background jobs
Clean old revisions, expired transients and orphaned data, then check what is autoloading on every request. We walk through it safely in optimizing the WordPress database. Also look at what runs on a schedule. Spread backups, imports and email sends across different hours instead of stacking them.
Slow down imports and exports
cPanel lists demanding imports and exports among the causes, so break large product imports or migrations into smaller batches. Large media uploads are another one; before you raise PHP limits to push big files through, read how to find the real WordPress upload limit.
Step 3: Raise the limits, or move
Sometimes the site is clean and well cached and still hits the ceiling, because it is simply busy. Then you have two routes.
Ask your host to raise the limits. cPanel states that on CloudLinux servers the limits are commonly set in WHM under Server Configuration, then CloudLinux Manager, in the Users or Packages tabs. That is a server-admin screen. On shared hosting you cannot open it, so you need support to adjust it, and most shared hosts will only do so by moving you up a plan. On a VPS or dedicated server, you control it yourself.
Move to a plan with more headroom. Here is how to think about it.
| Situation | Likely right fit |
|---|---|
| Small brochure site, occasional 508 after a bot burst | Stay on shared; block the bots, add caching |
| Growing WordPress or WooCommerce site with steady spikes | A WordPress plan with more resources |
| Several client sites in one account | Reseller hosting |
| Custom stack, traffic spikes, need root access | VPS or cloud server |
| Sustained heavy load or large databases | Dedicated server |
A useful rule: if you have fixed the obvious causes and Resource Usage still shows the same limit being hit during ordinary business hours, you are paying for a plan your site has outgrown. Upgrading then costs less than the sales you lose to error pages.
Our perspective
Most 508 tickets we see are not capacity problems at first. They are a site doing unnecessary work: no page cache, a bot hammering the login, a backup plugin running at noon. We always tell people to fix those before paying for a bigger plan, because a bigger plan with the same habits just hits the next ceiling later.
But we also do not pretend that tuning solves everything. If a site is healthy and growing, hitting a limit is a sign of success, and the honest answer is a plan that fits it. Our SRE and DevOps engineers in the EU and US look at the same graphs described above, and we would rather show you the log line that proves the cause than sell you an upgrade you do not need. That is also why we offer free migration and a 30-day money-back guarantee: moving should not feel like a gamble.
— Ihor
Stopping it from coming back
Once the site is stable, a few habits keep it that way.
- Check Resource Usage monthly, not only when something breaks. A slow upward trend is easy to spot on a graph and hard to notice on the site.
- Keep one caching layer, correctly configured, rather than several overlapping plugins.
- Update and prune plugins. Every deactivated plugin you do not need is risk and clutter. Fewer active plugins means less memory per request.
- Put a CDN in front of static files so images, scripts and styles do not occupy your concurrent connections.
- Stagger scheduled tasks so backups, scans and imports never overlap.
- Test before big events. A sale, newsletter or product launch can multiply simultaneous requests in minutes. Warm your cache and check headroom beforehand.
- Keep a baseline. Note your normal CPU, memory and entry-process peaks. When a new number looks odd, you will know it.
For more general advice on balancing speed, security and cost, see our essential WordPress hosting tips.
When a bigger plan is the right answer
If you have cached, blocked and trimmed, and the graphs still hit a wall, we can help you move without downtime. Our shared hosting plans suit small sites, our WordPress hosting plans add resources and tools tuned for WordPress, and our VPS plans give you control of your own limits. Migration is free, daily backups are included, and you have 30 days to decide whether it fixed the problem.
If you manage several sites, reseller hosting keeps each client in its own account. For heavy workloads, look at our dedicated servers. Not sure which fits? Send support your Resource Usage screenshot and the log lines from the spike, and we will tell you plainly whether you need tuning or a new plan.
FAQ
Will the 508 error go away by itself?
Often, yes, because the cap applies to a moving window of usage and the page recovers when the load drops. But if the cause is a bot or a heavy job that keeps running, it will return. Treat a repeat as a signal to check Resource Usage and the logs rather than wait.
Does a 508 error hurt my SEO?
A short blip is unlikely to matter much. Frequent errors are worse, because crawlers and visitors both find pages that will not load. Fix the cause quickly and confirm in your logs that the error is no longer served to search crawlers.
Is the 508 error my fault or my host's?
It is a limit on your account, so the trigger is usually on your site: traffic, a bot, a plugin or a job. That said, a host that sets limits too tight for the plan it sold you is also part of the picture. Look at the graph, fix what you can, and ask support what the limits are.
Can I just increase the limits myself in cPanel?
Not on shared hosting. The limits are set by the server administrator, in tools such as WHM's CloudLinux Manager, which customers do not have access to. You can ask your host to adjust them, or move to a VPS where you manage resources directly.
What is the difference between a 508 and a 503?
A 508 specifically points to the concurrent-connection limit, while a 503 can come from memory or process limits, or from the server being down or overloaded. Both are covered by the same investigation: check Resource Usage and the error log at the time of failure.
Sources
- Receiving a "508 Resource Limit Is Reached" error, cPanel support
- Sites slow or not loading: LSAPI_CHILDREN, cPanel support
- Limits, CloudLinux OS documentation
- Error 1102, Cloudflare Support docs
- Is Wordfence the cause of a 508 error, WordPress.org support
- 508 Resource Limit Is Reached, entry processes and memory rising, WordPress.org support