The email from your host is polite and vague: your account “has been reaching its resource limits”. Or there was no email at all, and you only noticed because the site crawled through Tuesday lunchtime, showed a “Resource Limit Is Reached” page to a customer, and then behaved perfectly well again by evening.
Shared hosting resource limits are the reason. Every account on a shared server is fenced in, so that one busy site cannot starve the others. When your site presses against one of those fences, it slows down or starts refusing requests. The useful question is not just “which limit?” but “what pushed the site into it?”, because the answer is often something you can change without moving to a bigger plan.
If you want to know what the figures on a plan mean and how to size one, our guide to how much hosting a small business site needs covers that. This post is about the moment the limit is hit: what each one looks like from the outside, what usually causes it, and what to do.
Why the limits exist
A shared server runs many customers’ accounts on one machine. Without limits, a single site with a runaway plugin or a flood of bot traffic could use the whole processor and slow every other site on the server. Most hosts therefore cap each account’s share. Many use a system called CloudLinux for this, which is why cPanel accounts often show the same set of meters, but other panels have their own versions.
The important point is that hitting a limit does not usually take the site down completely. The host throttles it, queues it or rejects some requests, and the effect comes and goes with load. That is why it is so often mistaken for a vague “the site is slow sometimes” problem.
Each limit, what it looks like, what usually causes it
CPU: the site gets slow, but still loads
When an account reaches its processor allowance, the host slows it down rather than stopping it. Pages take longer to start, the admin feels sticky, and nothing shows an error. This is the most common reason behind the complaint “CPU limit reached, website slow”.
Typical causes:
- Lots of uncached page views at once: a campaign, a sale, a post shared widely.
- A plugin running heavy database queries on every request.
- Crawlers requesting thousands of pages, especially search results and filter combinations.
- A backup, image optimisation run or import working through the day.
Memory: errors on some pages, not others
Physical memory caps how much the account’s processes can hold at once. When it is exhausted, processes are stopped and the visitor sees a 500 or 503 error, or a blank page. Heavy pages such as a large product category, a page builder editor or a report screen tend to fail first, while light pages keep working.
This is not the same as the PHP memory limit that WordPress mentions in a “memory exhausted” error. That one caps a single PHP process. The account limit caps all of them together.
Entry processes: the “Resource Limit Is Reached” page
Entry processes count how many requests your account is handling at the same instant. When they are all in use, the next request is turned away, often with a 508 “Resource Limit Is Reached” page. Visitors who refresh a few seconds later may get through, which makes it look random.
Requests that take a long time are the usual cause, more than sheer visitor numbers. A page waiting on a slow outside service, a long-running backup started from WordPress, or many simultaneous admin-ajax calls each hold an entry process while they wait.
Number of processes: background jobs and stuck tasks
Some hosts also cap the total number of processes, including ones not serving visitors, such as cron jobs and email scripts. Hitting it can make scheduled jobs fail and, in some cases, stop new web requests. Overlapping cron runs and scripts that never finish are the usual cause.
Disk I/O: everything slow when files are being read or written
I/O limits cap how fast the account can read from and write to disk. Backups, large file uploads, image regeneration and plugins that write logs on every visit are common culprits. The symptom is a site that is slow in bursts, often at the same time each day, and backups that take far longer than they should.
Inodes: uploads, updates or email start to fail
An inode is one file or folder. Some plans cap the count. When it is reached, WordPress cannot write new files: uploads fail, updates fail partway, cache files cannot be created and mail may stop arriving. Old backup archives, huge cache folders, session files and thumbnail sizes from old themes are the usual reason.
Signs of shared hosting resource limits in your panel
In cPanel on CloudLinux servers, the Resource Usage page shows each limit as a graph over time, with a count of “faults”, meaning the moments the account hit a ceiling. Other panels label this as statistics, usage or resources.
Look at the last few weeks, not just today, and write down:
- Which limit had faults.
- The days and times they happened.
- Whether they cluster around one time of day or spread through working hours.
Then put those times next to what was happening on the site. A calendar helps more than you would expect. Faults every night at the same minute point to a scheduled task. Faults during a newsletter send point to real visitors. Faults at odd hours with no business reason often point to bots.
Finding what pushed the site over
The panel tells you which limit and when. It rarely tells you why. These checks fill the gap:
- Ask the host which URLs and IP addresses were busiest during the fault times. Many hosts can see this even when you cannot.
- Read the raw access log for the same times, if your panel provides it. Repeated requests from one address or user agent stand out quickly.
- Check WordPress’s scheduled tasks with a cron viewer plugin, and compare their run times with the faults.
- Load an uncached page with Query Monitor active to see whether one plugin is doing far more work than the others.
- Look at disk usage by folder for inode or I/O problems. Backup and cache folders inside wp-content are the first places to check.
If the busiest requests turn out to be crawlers, scrapers or login attempts, our post on bad bots using server resources goes through what to do about them.
Fixes that cost nothing, in rough order
- Get page caching working for every page that can be cached. Cached pages use a tiny fraction of the CPU and processes an uncached page does.
- Move heavy scheduled work to quiet hours, and stop backup plugins running full backups during the day.
- Store backups off the account. Archives kept in wp-content eat disk space and inodes, and creating them eats I/O.
- Replace or reconfigure the heaviest plugin that Query Monitor or the host’s logs point to.
- Block or slow down abusive bots rather than serving them at full speed.
- Clear old cache, session and log files that never get cleaned up.
After each change, watch the fault count for a week. If it drops to nothing, you were never short of hosting; the site was spending it badly.
When the limits are genuinely too small
Sometimes the evidence points the other way. Faults happen during normal business hours, the busiest requests come from real customers, pages are cached where they can be, and nothing on the site is wasteful. That is a site that has grown into its plan. Our post on when to upgrade hosting for speed sets out what to confirm and what to ask before you move, and our group guide on what hosting can and cannot change about speed explains which problems a bigger plan will not touch.
Resource limits are one of the server-side topics in our wider guide to making a website faster, where the page-side work is covered too.
Frequently asked questions
Can the host suspend my account for hitting resource limits?
Some hosts will, if an account keeps using far more than its share and affects other customers. More often they throttle the account or send a warning first. Their terms of service usually describe what happens, so read that section and keep any warning emails, since they often include the times and causes they saw.
Why do I hit limits when my visitor numbers are low?
Visitor counts from analytics only include real people whose browsers ran the tracking code. Bots, background plugin requests, the admin area and scheduled tasks all use server resources without appearing in those numbers. A quiet site in analytics can still be busy for the server.
Does a CDN reduce shared hosting resource use?
It helps with images, stylesheets and scripts, which the CDN then serves instead of your account, and it can filter some junk traffic before it arrives. It does not reduce the PHP work for uncached pages, the admin or background requests, which are what usually push accounts into their CPU and process limits.
Is the 508 error my site’s fault or the host’s?
It means your account reached its own concurrent-process limit, so it starts on your side, even though the host set the limit. The cause is usually long-running or numerous uncached requests. If the host’s own logs show your account was well under its limit when the error appeared, then it is worth raising with them as a server fault.
When the fault counts keep climbing and the cause stays hidden, a second pair of eyes helps. Our speed optimisation service looks at caching, the database and server response time together. Many slow sites improve without a hosting change; where the plan really is the bottleneck, we say so clearly and suggest a specific upgrade rather than a general upsell.
Next in this series: Is WP-Cron Slowing Your Website? Take It Off Visitors
