Understanding cPanel Resource Limits and Fixing the ‘Resource Limit Reached’ Error

Seeing a bright red “Resource Limit Reached” warning in cPanel can be confusing and frustrating, especially if you are not sure what CPU, IO, EP or RAM limits really mean in practice. In most shared hosting environments, these limits are how your provider makes sure one account cannot slow down everyone else on the same server. They are not random restrictions; they are guard rails. When you understand how these resource limits work, you can usually solve the issue with a mix of optimisation and, when necessary, the right hosting upgrade.

In this article, we’ll walk through how cPanel resource limits work (especially on CloudLinux-based systems), what each metric actually measures, why the “Resource Limit Reached” message appears, and what you can do to fix it. We’ll look at real-world scenarios we see every week at dchost.com: WordPress sites under bot traffic, WooCommerce stores running heavy queries, cron jobs that run too often, and PHP applications with memory leaks. By the end, you’ll know how to read your own cPanel graphs, which settings you can tune yourself, and when it makes sense to move from shared hosting to a VPS or dedicated server.

Why cPanel Shows “Resource Limit Reached”

On most modern cPanel hosting platforms, resource limits are implemented using technologies like CloudLinux LVE (Lightweight Virtual Environment). Each cPanel account gets its own container with fixed limits for CPU, memory, disk IO, entry processes and sometimes the number of processes. When your site exceeds one of those limits, the server does not normally crash. Instead, your account is temporarily throttled or new requests are queued/blocked until usage falls back under the limit.

That’s when you see errors such as:

• “Resource Limit Reached” (generic message)
• “508 Resource Limit Is Reached” (HTTP status code)
• Slow page loads or intermittent 500 errors when traffic spikes

These are signals that your site is hitting one or more of the following limits:

• CPU usage (vCPU share or percentage)
• Physical memory (RAM)
• IO / IOPS (how fast your account can read/write to disk)
• EP (Entry Processes – concurrent web/PHP processes)
• NPROC (number of processes, if enforced)

The good news: in many cases this is fixable without moving to a completely different platform. But first you need to know what each metric means.

How cPanel Resource Limits Work (CPU, RAM, IO, EP, NPROC)

Let’s break down the most important metrics you’ll see in cPanel’s “Resource Usage” section and explain how they behave in real workloads.

CPU Limit: How Much Processing Power You Get

CPU is how much processing time your account can use on the server’s CPU cores. It is usually shown as a percentage where 100% ≈ 1 vCPU core. So if your plan has a 100% limit, that usually means you can fully occupy one core; 200% means roughly two cores, and so on (exact details can depend on the provider’s configuration).

Typical causes of high CPU usage include:

• Heavy PHP applications (WordPress, WooCommerce, Laravel, custom apps)
• Badly coded or outdated plugins/themes
• Search or reporting features that run expensive database queries
• Brute-force attacks, bots and scraper traffic hitting dynamic pages
• Misconfigured cache (or no cache at all) serving everything dynamically

When you hit the CPU limit, processes may be throttled. This usually shows up as slow responses or timeouts at peak times. If you run performance-sensitive sites, it’s worth pairing CPU optimisation with the hosting-side improvements we discuss in our article on how server choices affect Core Web Vitals like TTFB and LCP.

Physical Memory (RAM): How Much Your Scripts Can Hold in Memory

Physical memory (often labeled as “PMem” in CloudLinux) is the amount of RAM your account can actively use at once. This includes:

• PHP process memory (including OPCache, PHP arrays/objects, etc.)
• Per-request memory for each visitor
• Memory used by background scripts/cron jobs owned by your account

If your code or plugins are memory hungry, or if too many PHP processes run at once, you may hit the RAM limit. When that happens, new processes can be killed with errors like “Allowed memory size exhausted” or generic 500 errors.

Common triggers:

• Large WooCommerce product imports or exports
• Image processing (thumbnail generation, PDF generation)
• Backup plugins creating full-site archives in PHP
• Memory leaks in custom scripts

IO and IOPS: How Fast You Can Read/Write to Disk

IO is the data transfer speed limit between your account and the storage (measured in MB/s). IOPS (Input/Output Operations Per Second) limits how many operations you can do per second.

These are separate from CPU; you can have low CPU usage and still choke on IO if your site is constantly reading/writing small files or waiting on slow queries that spill to disk.

Typical causes of high IO / IOPS usage:

• Backup plugins writing many large archive files
• Log files growing too quickly (debug logs left enabled)
• Very frequent cache invalidation or cache plugins writing many small files
• Database tables that are heavily fragmented, causing more disk IO

If you are curious how much disk performance can matter for dynamic sites, especially on NVMe storage, we explain this in detail in our NVMe VPS hosting guide and real-world performance wins.

EP (Entry Processes): How Many Requests Can Be Served at the Same Time

EP (Entry Processes) is one of the most misunderstood metrics. In CloudLinux-based hosting, an entry process is essentially a concurrent request entering the LVE, such as:

• A PHP script executed via Apache or Nginx + PHP handler
• A CGI or FastCGI process
• Some cron-executed scripts (depending on configuration)

It is not the total number of visitors per minute; it is how many of them are in progress at the same time. For example, if a page takes 2 seconds to generate and you have 20 concurrent visitors requesting dynamic pages, that can easily hit an EP limit of 20.

Symptoms of hitting EP limits:

• Some visitors see 508 errors while others load fine
• Site feels fine under light traffic but collapses during short spikes (campaigns, ad clicks, email newsletters)

Improving caching and reducing per-request work is usually the best way to bring EP usage under control.

NPROC: Number of Processes

NPROC is the total number of processes your user can have running at once. This includes PHP, cron jobs, shell scripts, and sometimes other binaries. On many shared plans this is generous enough that legitimate sites never hit it; it’s primarily a safety net against runaway scripts spawning too many children.

If you do see NPROC limits, it’s often because of:

• Infinite loops or badly written background scripts
• Multiple overlapping cron jobs that take longer than their scheduling interval
• Malware or hacked scripts spawning extra processes

How to Read cPanel’s Resource Usage Graphs

Before you change anything, it’s important to collect evidence. cPanel makes this fairly easy if your hosting is running CloudLinux or similar.

Step 1: Open the “Resource Usage” Tool

1. Log in to your cPanel account.
2. Look for a section called “Metrics” or similar.
3. Click on “Resource Usage” (sometimes labeled “CPU and Concurrent Connection Usage”).

At the top, you’ll see a status message such as:

• “Your site had no issues in the past 24 hours”
• “Your account has reached resource limits in the past 24 hours”

Step 2: Check Which Limit Is Being Hit

Use the time range selector (last hour, last 24 hours, last week, etc.) and look at each graph:

• CPU Usage – Look for peaks touching the limit line.
• Physical Memory Usage – See if RAM usage flatlines at the limit.
• Entry Processes (EP) – Are there spikes hitting the cap?
• IO / IOPS – Any sustained plateaus at the maximum?

If you hover over a spike, you usually see the exact time. Correlate that with what was happening then: a marketing email, a backup schedule, a cron job, a new plugin, or a brute-force attack.

Step 3: Identify Patterns

Ask yourself:

• Do spikes happen at the same time every day? (usually a cron job or backup)
• Do they align with traffic peaks? (you may need more caching or more resources)
• Are they constant even without traffic? (possible background script issue or hack)

This basic detective work will guide which fixes make sense for your site.

Common Real‑World Causes of “Resource Limit Reached”

From our day-to-day work at dchost.com, we see a few recurring patterns whenever a customer hits resource limits on cPanel.

1. Uncached or Poorly Cached WordPress/WooCommerce

Dynamic CMS platforms like WordPress and WooCommerce are powerful, but they can be heavy if every visitor request triggers full PHP and database work. Without proper full-page caching and object caching, even moderate traffic can cause high CPU, EP and RAM usage.

Signs:

• High CPU and EP during normal browsing
• Database queries taking long under load
• Admin-ajax.php or wp-cron.php frequently appearing in access logs

2. Overactive wp-cron or Frequent Cron Jobs

By default, WordPress triggers wp-cron.php on regular page loads. On busy sites this can fire too often, creating many short-lived PHP processes and extra database queries.

We almost always recommend disabling pseudo-cron and switching to a real server-side cron job. If you are using WordPress on cPanel or a VPS, our step-by-step guide on how to disable wp-cron and set up real cron jobs walks you through this process in detail.

3. Backup Plugins Doing Heavy Lifting on Shared Hosting

Backup plugins that run full-site backups from PHP can cause:

• High IO / IOPS (writing large archive files)
• High CPU (compression and encryption)
• High RAM (building large archives in memory)

On shared hosting, this workload can easily hit multiple limits at once. It’s often better to let the hosting platform handle backups, or to push backups off-server using tools that are friendly to shared hosting.

4. Brute-Force Attacks and Bot Traffic

Attackers and aggressive bots don’t just threaten security; they also waste your resources. Repeated login attempts, XML-RPC abuse, and scraping can cause spikes in EP, CPU and memory usage.

If you use cPanel, it’s worth hardening your account against brute force and malware as part of your routine. Our cPanel security hardening checklist covers firewall rules, rate-limiting, and other measures that both improve security and reduce pointless resource consumption.

5. Inefficient Database Queries and Bloat

Over time, sites accumulate:

• Old post revisions and transients
• Abandoned carts and logs in WooCommerce
• Large options tables with autoloaded data

These can slow down queries, increase CPU and IO, and make each page request heavier than it needs to be. In some cases, moving to a dedicated database server (e.g. on a VPS or cluster) and tuning MySQL/MariaDB pays off; we’ve seen this repeatedly when following the principles we share in our real-world comparison of MariaDB, MySQL and PostgreSQL for web apps.

Step‑by‑Step Fixes Inside cPanel

Let’s look at practical changes you can make directly from cPanel (or your application) before considering a plan upgrade.

1. Update PHP Version and Enable OPcache

Newer PHP versions are usually faster and more memory efficient. Many cPanel setups with CloudLinux use “Select PHP Version” or similar.

1. In cPanel, open “Select PHP Version” or “MultiPHP Manager”.
2. Switch to a supported, modern PHP 8.x version (after verifying your app compatibility).
3. Enable OPcache and other recommended extensions.

PHP 8.x can bring significant performance gains. For a deeper dive into PHP upgrades and server-side tuning (including OPcache and FPM pool settings), see our detailed checklist on upgrading to PHP 8.x and tuning FPM for WordPress and Laravel.

2. Improve Caching for Dynamic Sites

Good caching reduces CPU, EP and sometimes memory usage dramatically:

• Full-page caching for anonymous visitors
• Browser caching for static assets (images, CSS, JS)
• Object caching for repeated database queries (Redis or similar, when available)

On many cPanel setups, you can:

• Enable server-side caching (depending on the webserver and modules your provider offers).
• Use a reputable caching plugin for WordPress (without overcomplicating the configuration).
• Configure static asset caching via .htaccess rules or the control panel.

Be careful with e-commerce storefronts or logged-in areas. Our guide on server-side optimisation for WordPress with PHP-FPM, OPcache, Redis and MySQL includes strategies to use full-page caching without breaking WooCommerce carts or personalised content.

3. Fix wp-cron and Other Scheduled Tasks

If you use WordPress, consider:

1. Adding define('DISABLE_WP_CRON', true); to wp-config.php.
2. Setting up a real cron job in cPanel (e.g. every 5 or 10 minutes) to call wp-cron.php directly.

This reduces the number of times cron runs and keeps it out of the main request path. For detailed, copy-paste-ready crontab examples and cPanel screenshots, follow our guide on disabling wp-cron and using real cron jobs.

Similarly, review other cron jobs in cPanel:

• Are they running more often than needed?
• Could heavy tasks (exports, reports) run at off-peak hours?
• Do any of them overlap because they take longer than expected?

4. Clean Up and Optimise Your Database

A cleaner database means less CPU and IO per request. For WordPress and WooCommerce you can:

• Remove old revisions, trash and spam comments.
• Clean up expired transients.
• Limit automatic post revisions in wp-config.php.
• Use tools to optimise tables (e.g., via phpMyAdmin’s “Optimize table”).

For custom applications, review your schema and indexes. Poor indexes can make every query slower and more resource-hungry, especially under load.

5. Reduce Plugin and Theme Bloat

Every plugin and theme brings extra PHP code, queries and possibly extra scripts/styles. On shared hosting, the difference between 10 lean plugins and 40 heavy ones is very visible in resource graphs.

Practical steps:

• Deactivate and remove plugins you truly don’t need.
• Avoid using multiple plugins for overlapping features (SEO, cache, security, forms).
• Choose themes known for performance rather than feature bloat.

6. Tighten Security to Block Malicious Resource Usage

Security and performance are closely linked. Each malicious request still consumes CPU, EP and IO. As part of your regular maintenance:

• Ensure strong passwords and 2FA for cPanel and CMS logins.
• Limit or disable XML-RPC if you don’t use it.
• Use application-level and server-side rate limiting where possible.
• Keep CMS, themes and plugins patched.

If you want a concrete, step-by-step to-do list for cPanel, bookmark our cPanel security hardening checklist to stop brute force and malware. Many of those measures pay off directly in reduced resource abuse.

When It’s Time to Upgrade: Shared vs VPS vs Dedicated

Even with careful optimisation, some projects eventually outgrow the fixed resource limits of shared hosting. That’s not a failure; it’s a sign that your site is attracting real traffic or doing serious work.

Signs You’ve Outgrown Shared Hosting

• Your cPanel graphs show frequent, sustained hitting of limits even after optimisation.
• Caching is already in place, PHP is updated, cron jobs are tuned, and you still see 508 errors on traffic peaks.
• You need custom server settings (e.g., higher PHP memory limit, specific modules, custom daemons) that shared hosting cannot provide.
• You run multiple sites/apps that would benefit from isolation and dedicated resources.

Moving from Shared Hosting to a VPS

On a VPS, you get dedicated vCPU, RAM and storage that are not shared at the same level as in a typical shared plan. You also gain root access, so you can tune services (web server, PHP-FPM, database) exactly for your workloads.

At dchost.com, we see many customers follow this path: start with shared hosting, optimise as far as possible, and then move the busiest sites to a managed or self-managed VPS. With the right migration plan, you don’t have to risk downtime or SEO issues. We’ve published a practical checklist on how to migrate from shared hosting to a VPS without downtime, including DNS and timing tips.

Choosing the Right Level of Resources

When upgrading, try to base your VPS specs on observed data rather than guesswork:

• Look at your peak CPU usage on shared hosting and multiply by a safety factor (e.g., 1.5–2x).
• Check peak RAM usage; include some headroom for database and caching.
• Consider NVMe storage for IO-heavy workloads (e-commerce, search, reporting).

If you’re unsure how to size your new environment, our article on capacity planning for WooCommerce (vCPU, RAM, IOPS) offers a practical way to estimate what you really need instead of overpaying or under-provisioning.

Dedicated Servers and Colocation

For very high-traffic sites, resource-heavy applications, or compliance-sensitive workloads, dedicated servers or colocation become attractive. You get full control over hardware resources, isolation, and network configuration without the noisy-neighbour problem of shared environments.

At dchost.com, we provide a full range of options—shared hosting, VPS, dedicated servers and colocation—so you can move up gradually as your resource needs grow, without having to re-architect everything from scratch every time.

Putting It All Together: A Calm Plan for Handling Resource Limits

The “Resource Limit Reached” message in cPanel is not a disaster; it’s a feedback signal telling you that your site’s current behaviour and your plan’s allocated CPU, RAM, IO and EP are not in balance. The right approach is methodical:

1. Measure: Use cPanel’s Resource Usage graphs to see which limits are actually being hit and when.
2. Optimise: Update PHP, enable OPcache, configure caching, clean up your database, tune cron jobs, reduce plugin/theme bloat, and harden security.
3. Monitor again: Watch the graphs after each change to confirm impact.
4. Decide: If you still hit limits under normal business-as-usual traffic, that’s a strong signal to upgrade to a VPS or dedicated server.

At dchost.com, our team regularly helps customers read their cPanel graphs, interpret CPU/IO/EP patterns, and decide whether optimisation or an upgrade is the better next step. If you’re consistently hitting resource limits and aren’t sure why, reach out with a support ticket including screenshots from the Resource Usage tool and a short description of your site. We can review the data with you, suggest concrete fixes, and, when it makes sense, help you plan a clean move to a VPS or dedicated server with enough headroom for the next stage of your project.

The key is not to wait until limits become a daily problem. Treat the first “Resource Limit Reached” warnings as an opportunity to optimise, improve performance, and plan your growth on infrastructure that matches where your site or application is heading.