Shared Hosting Resource Limits: What Happens When CPU, RAM or IO Max Out?

What are shared hosting resource limits and why do they exist?

Shared hosting resource limits are the caps a host places on each account for CPU time, memory, disk throughput, concurrent processes and file count. They stop one busy site from slowing down every other site on the same server. When your account hits a cap, pages slow down or return errors.

We are Talha Aslan and team, a digital marketing and web team; we are not a hosting company. For that reason, every technical definition in this guide comes from the official CloudLinux and cPanel documentation. Our goal is simple: you should be able to read the numbers in your control panel and take the right question to the right person.

In short, this guide gives you three things. First, you will learn what each limit actually measures. Next, you will recognize how your site behaves when a cap fills up. Finally, you will know which fixes you can handle yourself and which ones belong with your host.

Who enforces the limits on a shared server, and how?

On shared hosting, hundreds of accounts sit on the same physical or virtual machine. The host therefore needs a way to stop a single account from grabbing all the CPU or memory. On many cPanel servers, that job falls to the CloudLinux operating system and its LVE (Lightweight Virtual Environment) technology.

LVE treats each account like a small container with its own ceilings. For example, the PHP processes of one account cannot use more than their CPU share, and memory use stops at a fixed point. CageFS, which separates accounts at the file system level, is a different topic. We covered it in our CageFS guide, so we will not repeat it here.

That said, not every host runs CloudLinux. Some use another panel or other throttling tools. As a result, the names in your panel may differ from the ones in this guide. Still, the logic stays the same: CPU, memory, disk access, concurrent processes and file count are the core metrics everywhere.

What does the CPU limit (SPEED) measure?

The CPU limit caps how much processor power your account can use. CloudLinux documents it as SPEED and expresses it as a percentage of one core. In other words, 100% equals one full CPU core, and higher values mean more than one core.

Hitting this cap does not kill your processes. According to the documentation, a site that the system throttles on CPU or IO simply starts to respond more slowly. So the typical symptom of a CPU cap is not an error page; it is a page that takes too long to load.

What burns the most CPU? On a WordPress site without caching, every visit runs PHP from scratch and sends queries to the database. A heavy page builder, a long list of plugins or an inefficient search query multiplies that work. Moreover, the load grows with traffic: a hundred simultaneous requests means a hundred separate PHP runs.

Therefore, caching is the first place to look when a site keeps running into its CPU cap. For the PHP side, see our OPcache guide.

What happens when you exceed the RAM limit (PMEM)?

The RAM limit sets how much physical memory your account's processes may use at the same time. CloudLinux calls it PMEM. Its documentation notes that this value also counts shared memory and disk cache.

Memory, however, behaves differently from CPU. When an account reaches its PMEM cap, the system ends some of the processes inside it and increases a fault counter. The CloudLinux docs add that this usually makes the web server return 500 and 503 errors. In practice, a memory problem shows up as random error pages rather than general slowness.

In practice, large file jobs tend to eat the most memory. For instance, a plugin that resizes high resolution images on the server, an import of thousands of product rows, or a script that builds a backup archive can fill memory fast. Also note that PHP's own memory_limit setting and the account's PMEM cap are two different things. One limits a single PHP process; the other limits the whole account.

For that reason, raising memory_limit will not rescue a site that hits PMEM. In fact, if many processes run at once, it can make the problem worse.

How do IO and IOPS limits slow a site down?

The IO limit caps how much data your account can read from and write to disk per second. CloudLinux defines it as the combined total of reads and writes. IOPS, on the other hand, looks at the number of read and write operations per second rather than the amount of data.

When either cap fills up, the outcome looks similar: the system makes processes wait. According to the documentation, it throttles processes that hit the IO limit, in effect putting them to sleep. It does not stop them; it slows them down. Consequently, an IO problem also shows up first as slowness.

These jobs put the most pressure on disk access:

• Backups: Reading every file and database and writing them into one archive takes heavy disk work.
• File based cache purges: Deleting or rebuilding thousands of small cache files at once quickly runs into the IOPS cap.
• Log files: A site that leaves debug mode on writes a line to disk on every request.
• Large imports: Product or media imports stress both reads and writes at the same time.

Sites with many small files usually hit IOPS first, while sites with large files usually hit IO first.

What are entry processes (EP), and why do you see a 508 error?

Entry processes, or EP, are the number of processes entering your account at the same time. CloudLinux describes this limit as the number of concurrent connections to dynamic scripts in Apache. According to the docs, SSH sessions and cron jobs that run at the same moment also count toward it.

Here is an important distinction. EP is not the number of people on your site right now. For example, a static image or CSS file usually does not run PHP. A PHP request that finishes in a fraction of a second barely occupies a slot. Instead, the EP cap fills up when slow requests pile on top of each other.

What happens next? Per the documentation, the web server cannot place the new request inside the account's LVE and returns status code 508. Visitors then typically see a page titled "Resource Limit Is Reached". The default table in the CloudLinux docs lists 20 for EP; however, each host sets its own value per plan.

As an example, if a page normally takes half a second to build, the EP cap rarely fills. If the same page takes ten seconds because of a slow external API or a locked query, a handful of visitors can fill it. So a 508 error usually points to slow code rather than heavy traffic.

What does the NPROC limit restrict?

NPROC is the total number of processes that may exist inside your account at once. EP counts only the processes that enter the account. NPROC counts everything, including any child processes they start.

Think of it this way. A PHP request is one entry process. However, if that request launches an image processing command or a mail sending process in the background, NPROC goes up. Likewise, a backup script that cron starts may open several child processes.

According to CloudLinux, Apache may return 500 or 503 errors when NPROC fills up. That means the symptom looks like a memory problem: error pages. So when you see occasional 500 and 503 errors, check the process count as well as memory. For general causes and a fix order, see our 503 Service Unavailable guide.

On the other hand, NPROC trouble usually comes from one bad setup. Overlapping cron jobs, stuck background scripts and SSH sessions that never close are the classic examples.

What happens when you run out of inodes?

An inode is the record the server keeps for every file and folder. The cPanel documentation defines the File Usage line in the Statistics section as the number of files and directories, or inodes, that your account uses. In other words, the inode limit caps the count of files, not their size.

Your inode quota can also run out even when disk space looks fine. For example, session folders that create a new file on each visit, cache directories that nobody clears, thousands of thumbnails, mailboxes full of old messages and leftover backup folders all push the number up fast.

CloudLinux describes two inode limits: soft and hard. You can exceed the soft limit for a while, and it acts as a warning. Once you reach the hard limit, however, the account cannot write new data to disk. At that point a plugin update may stop halfway, an uploaded image disappears, the mailbox stops accepting messages and cache files fail to appear.

In short, an inode problem produces sudden and odd errors: the site loads, but forms do not send and updates never finish.

How do disk space and bandwidth limits work?

Disk space is the total size of your files, databases and email. The cPanel Statistics section shows it on the Disk Usage line and lists database usage on a separate line. When the disk fills, the effect resembles the inode cap: new files cannot land, backups fail and database tables cannot grow.

Bandwidth, or traffic, is the amount of data your site sends out. The cPanel docs define the Bandwidth line as the data transferred during the current month. On some plans the host suspends the site when the monthly quota runs out; on others you only get a warning. That behavior depends entirely on your provider's policy.

We explain how bandwidth quotas work and how to estimate your needs in our hosting bandwidth guide. One point is worth stressing here: oversized images and self hosted videos burn through traffic faster than anything else.

Also, old backups that pile up inside the account inflate disk space and inode count at the same time. Moving them off the account relieves both caps at once.

Why do MySQL connection and query limits matter?

The database has its own caps, and site owners often overlook them. MySQL lets an administrator set resource limits per account. The official MySQL documentation explains that separate caps can apply to queries per hour, updates per hour, connections per hour and simultaneous connections.

On shared hosting, the cap you meet most often is simultaneous connections. Once it fills, your site cannot reach the database, and systems like WordPress show an "error establishing a database connection" message. Meanwhile, the error log usually contains a line that mentions max_user_connections.

Some CloudLinux servers also run a component called MySQL Governor that tracks database usage per user. Whether your host enables it, and with which thresholds, depends on the provider. You cannot always see it in your panel.

Specifically, three things strain database caps the most: persistent connections that never close, plugins that run dozens of queries on every page, and searches on large tables without indexes. So when you see a database error, start with slow queries and plugins that open connections.

Which symptom points to which limit?

The table below summarizes how shared hosting resource limits typically show up when each one fills, and where to look first. The symptoms come from the CloudLinux and cPanel documentation; your host's setup may change the details slightly.

A rule of thumb helps when you read it: slowness usually means CPU or IO, while error pages usually mean memory, processes or EP.

How do you check resource usage in cPanel?

cPanel gives you resource data in two places. The first is the Statistics section on the home screen. According to the cPanel docs, it shows disk usage, file usage (inodes), monthly bandwidth and database disk usage, among other values. The same docs note that the CPU Usage, Memory Usage and Entry Processes lines appear only on servers that run CloudLinux.

The second place goes deeper. Per the CloudLinux documentation, end users open the Resource Usage plugin by clicking the "CPU and concurrent connection usage" tile in the Metrics section of cPanel. If your panel uses another language or theme, the label may look slightly different.

The screen has three tabs:

1. Dashboard: It tells you whether the system has limited your site recently and which resource hit the cap.
2. Current usage: It presents usage in charts and tables, with usage, limit and fault count side by side.
3. Snapshot: It holds point in time captures of the process list, database queries and HTTP requests.

If cPanel is new to you, start with our cPanel beginner's guide.

How do you read the fault counter and the Snapshot tab?

The most useful column in the Current usage table is the fault count. It tells you how many times a resource hit its cap. If usage is high but faults stay at zero, your site came close but did not get throttled. If faults keep climbing, your visitors saw slowness or errors at those moments.

You can narrow the charts to days, hours or minutes. That way you can tell whether the problem repeats at the same time every day or shows up at random. An IO chart that spikes at the same hour every night usually points to a backup or a cron job.

The Snapshot tab answers a simple question: what was running at that moment? In the process list, you can see which script used the most CPU or memory. The HTTP section shows which URLs received requests, and the database section lists the queries that ran.

For example, if a snapshot shows hundreds of requests to the same search URL, bot traffic is the likely cause. In contrast, if a single admin script runs for a long time, the culprit is probably a plugin or a scheduled task.

Where should you start when a site keeps hitting its caps?

A fixed order saves time. First, check the Dashboard to see which resource the system limited. Then find the time pattern in that resource's chart. After that, match it against the snapshots from the same moment.

In our field experience, these are the most common reasons a shared hosting account hits its caps:

• Plugins: Statistics, security scanning or related posts plugins that run heavy queries on every page.
• Bot traffic: Non search crawlers, price scrapers and brute force login attempts.
• Cron jobs: Scheduled tasks that run too often or overlap.
• Backup timing: Full account backups that run during peak traffic.
• Large backups: Archives that pile up inside the account and eat disk space and inodes.

After each change, watch the results for a few days. One quiet day with zero faults does not prove the fix worked. For server side slowness in general, see our guide on server side causes of a slow website.

How does bot traffic eat into shared hosting resource limits?

Because they never pause, bots request pages much faster, and in much larger numbers, than human visitors. On a site without caching, every bot request means a full PHP run. As a result, even an ordinary crawler wave can fill the EP and CPU caps in minutes.

Still, blocking every bot is a mistake. Cutting off search crawlers such as Googlebot hurts your visibility. So first confirm that a request really comes from the bot it claims to be; we explain the method in our Googlebot verification guide.

According to Google's official documentation, Google's crawlers temporarily slow down crawling when a server returns 5xx errors or a 429 status. In other words, a site that keeps hitting its caps does not only lose visitors; it may also lose crawl rate.

You can steer well behaved bots with robots.txt, and our robots.txt generator makes that file easy to build. On the other hand, malicious bots ignore robots.txt. For those, your host's firewall or a CDN layer in front of your site works better.

Why do cron jobs and backup windows cause sudden spikes?

Scheduled tasks are the most common reason for spikes that repeat at regular intervals in your resource charts. WordPress's built in scheduler, WP-Cron, is not a real server cron; it runs whenever visitors load pages. On a busy site, that can mean it runs far more often than necessary.

WordPress documentation suggests turning off the built in scheduler by adding this line to wp-config.php and then setting up a real cron job instead:

define( 'DISABLE_WP_CRON', true );

Next, add a task in the Cron Jobs screen of cPanel that runs wp-cron.php at a set interval. Take the PHP path from your host's documentation. For a step by step setup, see our cron job guide.

Backups, meanwhile, consume more IO and memory in one go than any other task. So schedule your backup plugin for your lowest traffic hour, and avoid running other heavy jobs at the same time. Also, send backups to remote storage instead of keeping them inside the account; our website backup strategy guide shows a sound setup.

The right fix order: from caching to a plan upgrade

When a site keeps hitting its caps, the first instinct is often to upgrade. However, upgrading before you fix the cause can simply move the same problem to a pricier plan. We suggest this order:

1. Caching: Page caching and PHP opcode caching remove work that the server would otherwise repeat on every visit. The biggest gain usually comes from here.
2. Bot blocking: Stop crawlers you cannot verify or do not need, and leave search engine bots alone.
3. Code and plugins: Remove unused plugins, swap heavy ones for lighter options and fix slow queries.
4. Timing: Move cron and backup windows away from peak traffic.
5. Plan upgrade: If faults still appear regularly after these steps, your site has genuinely grown.

Once you decide to upgrade, our guide to upgrading your hosting plan without downtime walks you through the switch. If you think shared hosting no longer fits, our VPS vs cloud server vs VDS comparison clarifies the next step.

Do "unlimited" hosting plans really have no limits?

No. Hosts usually apply the word unlimited to a single item, such as disk space or traffic. CPU, memory, concurrent processes and inodes remain physically finite on a shared server. That is why CPU, RAM and EP caps still apply on "unlimited" plans.

In addition, many providers add a fair use clause to the terms of their unlimited plans. In theory there is no cap; in practice, if your account strains the server noticeably, the host may contact you or restrict the account.

We cover this topic in more depth in a separate article. For now, one tip: when you compare plans, ignore the word "unlimited" and look at the CPU, RAM, EP, IO and inode values. If the plan page does not list them, ask the host for them in writing before you buy. For broader selection criteria, our guide to choosing web hosting helps.

What should you ask your hosting provider?

The right questions speed up any conversation with your host, whether you are choosing a plan or troubleshooting shared hosting resource limits. Here is the list we use:

• What exactly are the CPU, RAM, IO, IOPS, EP and NPROC values on my plan?
• Is there an inode cap, and if so, what are the soft and hard values?
• Do you apply a MySQL simultaneous connection cap or an hourly query cap?
• When the monthly traffic quota runs out, do you suspend the site or only send a warning?
• Is the Resource Usage screen active on my account, and how far back does its history go?
• Which limits produced faults on my account in the past week, and at what times?
• Do you run bot or brute force protection at the server level?
• Does moving to a higher plan involve downtime or an IP change?

Be specific when you report a problem, too. Instead of "the site is slow", write something like "IO faults rise every night at a certain hour, and the snapshot shows the backup script running". That sentence sends the support team straight to the right place.

When should you leave it to your host instead of fixing it yourself?

On shared hosting, your control ends at your own account. Plugins, cache settings, cron timing, robots.txt and file cleanup are your job. Anything about the server itself, however, belongs to the provider.

In these cases, open a support ticket instead of experimenting:

• Your site is slow but shows no faults: the problem probably affects the whole server.
• The snapshot shows processes you do not recognize: this could be a security issue.
• You suspect someone changed your limit values: only the host can confirm that.
• You face a brute force or denial of service attack: network level blocking is the host's job.

On the flip side, expecting the host to fix site level problems is not realistic either. A hosting company usually will not optimize your plugins or theme. For that kind of work, your developer or our web design and development team is the better fit.

A short checklist for managing shared hosting resource limits

This guide boils down to a few habits you can repeat. Once a month, open the Resource Usage screen and check the fault column. Then note how full your disk space and inode count are in the Statistics section.

Also, watch the resource charts for a few days after you install any new plugin. Make sure backup and cron windows do not overlap with peak traffic. Move old backups and unused files out of the account.

Finally, keep a written record of your plan values. That way, when something goes wrong, you can compare notes with your host and spot what changed. Shared hosting resource limits exist to protect everyone on the server, not to punish you; once you learn to read them, most slowdowns and error pages turn into predictable problems.

Sources: CloudLinux limits documentation, CloudLinux Resource Usage plugin, cPanel interface documentation, MySQL account resource limits, Google Search Central: HTTP and network errors.