Understanding Shared Hosting Resource Limits: CPU, RAM, and Disk Explained

Overview

Shared hosting resource limits are one of the most misunderstood parts of running a website on a shared plan. You sign up, everything works fine for months, then one day your site slows to a crawl or throws a 503 error — and you have no idea why. Nine times out of ten, it’s a resource limit being hit.

On a shared plan, your account shares physical server resources (CPU cores, RAM, disk I/O) with other accounts on the same machine. Hosts enforce per-account limits so one busy site can’t drag down everyone else. Understanding what those limits are — and how to read the signals when you’re close to them — will save you a lot of frustration.

This article covers how shared hosting limits work in cPanel environments, what the actual numbers mean, and how to figure out whether an upgrade is genuinely necessary or whether your site just needs some housekeeping. If you want to see what’s included on our plans, check out our Shared Hosting page.

Prerequisites

• Access to your cPanel account (any recent version — cPanel 104 or newer is most common in 2026)
• Your hosting login credentials
• Basic familiarity with your site’s CMS or application (WordPress, Drupal, custom PHP, etc.)
• Optional: SSH access if your plan includes it, for deeper diagnostics

What Resource Limits Actually Cover

Before jumping into troubleshooting, you need to know what’s being measured. Shared hosting plans typically limit four things:

• CPU usage — measured in percentages or “CPU seconds” per time window. Not raw GHz.
• RAM (physical memory) — usually a soft cap per process, not total RAM for your account.
• Disk space — total storage for files, databases, email, and logs combined.
• Inodes — the number of files and directories your account can hold, regardless of size.

Disk I/O (read/write speed) is also throttled on most hosts, though it’s rarely shown in control panels. If your site feels slow but your CPU and RAM look fine, I/O throttling is often the actual culprit — especially on plans using older HDD-based storage.

Step-by-Step: Checking Your Resource Usage in cPanel

1. Log in to cPanel. Your URL is typically yourdomain.com/cpanel or the server’s hostname on port 2083.

2. Find the resource usage widget. On the cPanel home screen, scroll to the Statistics sidebar on the right. You’ll see live readings for Disk Usage, Bandwidth, Email Accounts, and Databases. This is a quick snapshot, not a detailed breakdown.

3. Open the full Disk Usage tool. Click Disk Usage under the Files section. This shows per-directory usage and helps you find what’s consuming the most space — logs and email folders are common culprits.

4. Check your inode count. The Statistics sidebar shows your inode usage directly. If you’re at 80%+ of your inode limit, this will cause file creation failures even if you have plenty of disk space left. More on this below.

5. View CPU and memory usage (CloudLinux accounts). If your host runs CloudLinux (most shared hosts do in 2026), you’ll have a Resource Usage icon in cPanel, sometimes labelled CPU and Concurrent Connection Usage. Click it to see a graph of your CPU, RAM, and entry process usage over the last 24 hours.

   📝 Note: If you don’t see this icon, your host may not be using CloudLinux, and per-account CPU/RAM graphs may not be available to you. Contact support and ask for your LVE (Lightweight Virtual Environment) stats.

6. Read the graphs correctly. In the CloudLinux Resource Usage panel, look for red or orange bars. These represent periods where your account hit its limit and requests were throttled or queued. A few spikes are normal. Consistent red means you’re genuinely over-allocated.

7. Check your error logs for resource-related errors. In cPanel, go to Metrics > Errors to view your Apache error log. Look for entries like Resource temporarily unavailable or 508 Resource Limit Is Reached. These confirm throttling is happening.

   You can also pull the last 50 lines via SSH if you have access:

   Copied to clipboard

   tail -50 ~/logs/yourdomain.com-ssl_log

Common Issues and Troubleshooting

508 Resource Limit Is Reached

This is the HTTP 508 error you see when your account exceeds its concurrent process limit. It usually means too many PHP processes are running at the same time — often triggered by a traffic spike, a runaway cron job, or a plugin doing something stupid in the background.

Short-term fix: disable any recently installed plugins or check for cron jobs running at high frequency. In cPanel, go to Advanced > Cron Jobs and look for anything running every minute. Long-term, if your site regularly serves real traffic volumes, a VPS plan gives you dedicated resources and eliminates this problem entirely.

Inode Limit Reached — Files Won’t Upload or Emails Bounce

This one surprises a lot of people. You can have gigabytes of disk space free but still be unable to create new files, send emails, or update your CMS because you’ve hit your inode cap.

The most common cause I see: WordPress sites with backup plugins configured to store hundreds of incremental backups locally, or mail accounts with tens of thousands of individual messages sitting in ~/mail/. Check your inode count in cPanel’s Statistics panel, then run this via SSH to find the directories with the most files:

find ~/ -xdev -printf '%h
' | sort | uniq -c | sort -rn | head -20

Delete old backups, purge email trash folders, and consider storing backups off-server (S3, Backblaze, etc.).

Site Is Slow But CPU and RAM Look Normal

If your resource graphs look fine but the site still feels sluggish, you’re likely hitting disk I/O throttling or MySQL query limits. Shared hosting plans throttle I/O at the infrastructure level — it won’t show in your cPanel graphs.

Test database query performance by enabling the slow query log temporarily, or use a plugin like Query Monitor (for WordPress). Persistent slowness despite low CPU is a strong signal that you’ve outgrown the shared environment. In my experience, WordPress sites doing more than 1,000 visits/day on shared hosting almost always benefit from moving to a VPS or managed WordPress plan.

Disk Space Full But You’ve Deleted Files

You deleted files through your FTP client or file manager, but disk usage hasn’t changed. The most likely cause: a running process still has the deleted file open, so the space isn’t released until that process restarts. This is a common Linux gotcha.

Also check your cPanel Trash/Backups within the File Manager — deleted files sometimes go there first. And check email: a single mailbox with months of unread newsletters can hold several gigabytes.

Entry Process Limit Errors (CloudLinux EP Limit)

The Entry Processes metric in CloudLinux limits how many simultaneous connections can enter your account’s PHP environment at once. Default limits on shared plans are often 10–20 EP. A burst of traffic or a slow PHP script holding connections open will push you over this fast.

⚠ Warning: Don’t just ask your host to raise the EP limit without investigating why processes are slow in the first place. Raising EP on a slow application just queues more requests — it doesn’t fix the underlying performance issue.

Identify slow scripts by checking your access log for requests taking more than 2 seconds:

awk '$NF > 2 {print $7, $NF}' ~/logs/yourdomain.com-ssl_log | sort -k2 -rn | head -20

When to Upgrade

Shared hosting limits aren’t a flaw — they’re the model. But there are clear signals that you’ve genuinely grown beyond a shared environment:

• You’re hitting CPU or EP limits daily, not just during traffic spikes
• Your site requires persistent background processes (queue workers, WebSockets)
• You need root access to install custom software or PHP extensions not available on shared
• Database size is consistently over 1GB and query performance is degrading

At that point, a VPS (starting at $5.83/mo at Host & Tech) gives you guaranteed CPU and RAM, full root access, and no noisy neighbours. It’s not dramatically more expensive at the entry level, and the performance difference for a growing site is real.

FAQ