Understanding cPanel Resource Limits (CPU, EP, IOPS, Memory)

If you’ve ever logged into cPanel and noticed numbers next to “CPU Usage” or “Entry Processes” creeping toward 100%, you’ve met CloudLinux — the layer that enforces resource limits on shared hosting. Hitting those limits doesn’t always crash your site, but it does throttle it. This guide explains what each limit is, what triggers it, and what to do when you start seeing warnings.

Where to see your limits

cPanel → Metrics → Resource Usage. You’ll see a snapshot view (current usage), historical usage, and a “Faults” tab showing each time you hit a limit. The faults tab is the one to watch — it lists exact times and which limit was triggered.

The five limits, in plain terms

CPU — the most common limit

CPU is measured as a percentage of one CPU core’s time. So 100% CPU means your account is using all of one core continuously. 200% means two cores. Most shared plans are between 100–400% (1 to 4 cores).

Common causes of high CPU:

• Unoptimized WordPress. No caching, heavy theme, dozens of plugins. Single biggest cause we see.
• Bots scraping your site. AhrefsBot, SemrushBot, scrapers, and AI training crawlers can hammer a site relentlessly.
• WP-Cron running too often. Default WordPress fires wp-cron.php on every page load — under load this multiplies.
• Hostile traffic. Brute-force login attempts on /wp-login.php or /xmlrpc.php.
• Inefficient queries. Custom code or plugins running full-table scans on every request.

Entry Processes (EP) — what trips it

An “entry process” is a PHP request being processed right now. Most plans cap at 20–40 concurrent EP. If 41 visitors land on dynamic pages at the same instant, the 41st gets a 503 page.

The fix isn’t always more EP — it’s making each request faster. A page that completes in 200ms can serve 5 visitors per second through one EP slot. A page that takes 5s only serves 1 visitor per 5 seconds. Caching converts dynamic requests to static — visitors hit Nginx or LiteSpeed directly instead of taking an EP slot.

IOPS — the silent killer

IOPS (Input/Output Operations Per Second) measures how often your site reads or writes to disk. Most shared plans cap around 1024–4096 IOPS. Hitting the cap doesn’t return an error — it just slows everything down because the kernel queues your I/O requests.

Common IOPS culprits:

• Logging plugins. WP Statistics or analytics plugins writing every page view to the database.
• Object cache misses. If your cache isn’t working, every request rebuilds it.
• Search plugins. WordPress’ default search is famously slow on large databases.
• Backup running mid-traffic. A large backup writes thousands of files — schedule them for low-traffic hours.

How to reduce resource usage

In rough order of impact:

1. Install a real caching plugin. LiteSpeed Cache (free) is the obvious choice on iWebVault since our servers run LiteSpeed. Enable page cache, object cache, browser cache. Single biggest improvement for most WordPress sites.
2. Put Cloudflare in front. Free tier filters most bot traffic before it reaches your server. Setup guide here.
3. Disable WP-Cron and run via real cron. Add define('DISABLE_WP_CRON', true); to wp-config.php, then set up a cron in cPanel running every 5 minutes: wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1.
4. Block hostile bots. Edit robots.txt for compliant bots (AhrefsBot, SemrushBot); use a security plugin or our server-level blocks for non-compliant ones.
5. Audit your plugins. Disable plugins one at a time and watch Resource Usage. The worst offenders usually announce themselves quickly.
6. Switch to PHP 8.2 or 8.3. Older PHP versions are slower. cPanel → Select PHP Version.

When to upgrade vs. when to optimize

The honest answer: optimize first. We’ve seen sites cut their CPU usage by 80% just by installing LiteSpeed Cache and putting Cloudflare in front — no plan upgrade needed.

Genuine signs you’ve outgrown shared hosting:

• Resource Usage shows sustained hits even with caching active and Cloudflare in front.
• Your site is consistently getting 30,000+ visitors per month per site.
• You need software shared hosting won’t allow (Node.js services, Redis, custom PHP extensions).
• You’re hitting EP limits during normal traffic, not just spikes.

Two or three of these = look at our VPS plans. One = optimization is probably still the cheaper win.

Common questions

“I’m hitting CPU but my site has no visitors right now.” A scheduled task is running — likely WP-Cron, a backup, or a bot crawl. Check the Faults tab in Resource Usage; correlate timestamps to your cron jobs.

“503 Service Unavailable on my homepage.” Hitting EP limit. First, install caching — the homepage being uncached is the most common cause. If caching is already on, look for what’s bypassing it (logged-in users, cart pages, AJAX endpoints).

“Resource Usage shows red but my site feels fine.” CloudLinux’s “faults” only happen when you exceed the limit. Seeing 70-80% usage is normal under traffic — only the actual fault counts matter.

“Should I just buy more CPU?” If you’ve already optimized and you’re still hitting limits, yes — upgrade. But upgrading without optimizing first usually means you’ll hit the new limit too in a few months. Optimize once, upgrade once, save the next round of upgrades.

What’s next

• Caching setup: install LiteSpeed Cache plugin in WordPress, enable page + object cache.
• Put Cloudflare in front of your site — biggest single-step improvement.
• Choosing the right hosting plan when optimization isn’t enough.

Resource limits aren’t a punishment — they’re what makes shared hosting affordable. The right response is almost always to make your site faster rather than buy more resources. Caching, Cloudflare, modern PHP: three changes that fix most resource issues.