Shared Hosting Resource Limits Explained: CPU, RAM, and Inodes

Shared hosting is the most accessible entry point for putting a website online, but the phrase "unlimited everything" that dominates shared hosting marketing pages is one of the most misleading promises in the technology industry. Every shared hosting plan has resource limits—CPU seconds, physical memory, entry processes, inode counts, I/O operations—and those limits are enforced by software that will throttle, suspend, or silently degrade your site when you cross them. Understanding shared hosting limits is not about finding a way around them. It is about knowing what you can realistically expect from a $3-to-$15-per-month hosting plan before your site outgrows it.

At HostingCaptain, we have tested shared hosting resource enforcement across 30+ providers, pushing test sites until they hit limits and documenting exactly what happens. This article is the result: a practical, technically specific guide to CPU, RAM, inode, I/O, and entry process limits that no shared hosting provider explains clearly in their public documentation.

What Shared Hosting Actually Is

Shared hosting places hundreds or thousands of customer accounts on a single physical server, with each account isolated at the operating system level by software like CloudLinux. Each account receives a slice of the server's total CPU, RAM, disk, and I/O capacity, and the isolation software enforces hard ceilings on each resource. The MDN web server explainer provides a good foundation for understanding how web servers handle resource allocation, and our shared hosting guide covers the business model in detail.

The key insight is that resource limits are not malicious. They are necessary. Without them, a single account running a runaway WordPress plugin could consume 100% of the server's CPU and degrade performance for every other site on the machine. CloudLinux and similar isolation layers are what make shared hosting viable at all. The question is not whether limits exist but whether they are set at a level that allows your site to function normally.

CPU Limits: The Most Misunderstood Resource

CPU limits on shared hosting are expressed in terms of CPU seconds, not percentages. A plan that offers "100 CPU seconds per day" means your processes can consume a cumulative total of 100 seconds of CPU time in any 24-hour period. For a typical WordPress site serving cached pages, each request might consume 0.05 CPU seconds, allowing 2,000 page views before hitting the daily ceiling. An uncached WooCommerce product page with dynamic pricing calculations might consume 0.5 CPU seconds per request, reducing that ceiling to 200 daily page views.

The most common CPU limit values we observe across shared hosting providers:

• Budget shared hosting ($2–$5 per month): 40–80 CPU seconds per day, which is suitable for a brochure site with a few hundred daily visitors.
• Mid-tier shared hosting ($6–$10 per month): 100–200 CPU seconds per day, adequate for a blog or small e-commerce site with moderate traffic.
• Premium shared hosting ($12–$20 per month): 200–400 CPU seconds per day, which can handle busier sites with dynamic content and plugin-heavy WordPress installations.

CPU throttling kicks in when you exhaust your allocation. The server does not shut down your site—it slows down your PHP processes, so requests that previously completed in 0.2 seconds now take 1.0 second, and concurrent requests queue up. Users experience slow page loads, and if the queue grows deep enough, the web server begins returning 503 or 508 (Resource Limit Reached) errors. The throttling is per-account, so one site on a multi-domain plan consuming excessive CPU can degrade all sites in your account simultaneously.

WordPress sites are disproportionately affected by CPU limits because every PHP page request invokes the WordPress bootstrap process, which loads the active theme and all active plugins. A site with 40 active plugins can consume 3–5× the CPU per request of a site with 5 plugins. Caching plugins that serve static HTML files bypass PHP entirely for anonymous visitors, which is why a properly cached site can survive on a budget shared plan while an uncached equivalent cannot. Understanding how DNS configuration interacts with hosting environments is covered in our DNS guide.

Physical Memory (RAM) Limits

Shared hosting RAM limits are enforced per-process, not per-account. A plan that specifies a 256 MB memory limit means each PHP process can use up to 256 MB of RAM before being terminated by the operating system's OOM (Out of Memory) handler. A plan that specifies 512 MB doubles that ceiling. The limit exists because PHP processes are spawned per-request, and a single runaway process that consumes 2 GB of RAM would starve other accounts on the server.

The practical impact of RAM limits depends on what your site does within a single PHP request. A simple WordPress page load that retrieves a few posts and renders a template might use 64–80 MB. A WooCommerce checkout that calculates shipping rates, applies discount rules, and updates inventory might use 180–200 MB. A backup plugin that attempts to zip a 500 MB uploads directory in a single process will almost certainly exceed any shared hosting RAM limit and trigger a process kill.

When a PHP process hits the RAM limit, it is terminated immediately, and the request returns a 500 error or a white screen. The termination is logged by CloudLinux or the equivalent isolation layer, and these logs are accessible in the hosting control panel under "Resource Usage" or "Error Logs." Monitoring these logs regularly is the only way to know whether your site is brushing against memory limits, because the failures are intermittent and depend on which specific request path triggers the high-memory code path.

The RAM limit is also why image-heavy WordPress sites cause problems on shared hosting. When WordPress generates thumbnail sizes for an uploaded image, the image library (GD or Imagick) loads the entire uncompressed image into memory. A 20 MB TIFF file uploaded by a client can consume over 200 MB of RAM during thumbnail generation, exceeding the limit on most shared plans. Offloading image processing to a service or plugin that processes images in smaller chunks is the standard workaround.

Inode Limits: The Hidden Ceiling on File Count

An inode is a filesystem data structure that represents a file or directory. Every file on your hosting account—every PHP file, every image, every cached HTML page, every email stored on the server, every log file—consumes one inode. Shared hosting plans enforce an inode limit, typically between 100,000 and 400,000 inodes, beyond which the filesystem refuses to create new files. Your site is still online, but WordPress cannot write new cache files, cannot accept new media uploads, and cannot generate new thumbnails. Email accounts stop receiving new messages because the mail server cannot write new mail files.

Inode exhaustion is insidious because it does not trigger an obvious error. The site appears to work, but behind the scenes, critical write operations are failing silently. Session files cannot be created, so users are logged out unexpectedly. WordPress updates fail because the update process cannot write new files to disk. The control panel's disk usage bar may show 60% capacity (indicating plenty of free space) while the inode counter shows 100% utilization (indicating the filesystem cannot accept new files). Two different resources, two different limits.

Common causes of inode exhaustion include:

• WordPress caching plugins that store millions of small cache files without an expiration policy.
• Email accounts storing years of messages, each message as a separate file in the mail directory.
• Session files accumulating because PHP's session garbage collection is misconfigured.
• Error log files that rotate but are not purged, accumulating thousands of log files over months.
• Backup plugins that store incremental backups as thousands of small files rather than a single archive.

Clearing cache files, purging old emails, and disabling session file storage in favor of database-based sessions can recover tens of thousands of inodes quickly. The control panel's inode usage counter updates daily on most providers, so monitor it monthly and investigate any sustained upward trend before it reaches the limit.

I/O Limits: The Speed Governor

I/O (input/output) limits cap how fast your account can read from and write to the server's physical disks. The limit is expressed in KB/s or IOPS (input/output operations per second). Typical shared hosting I/O limits range from 1 MB/s to 10 MB/s of throughput and 100–1,000 IOPS. To put those numbers in perspective, a SATA SSD can sustain approximately 500 MB/s and 90,000 IOPS, so a 2 MB/s shared hosting I/O limit represents 0.4% of the disk's actual capability—the rest is reserved for other accounts.

I/O limits matter most for database-heavy operations. WordPress, as a database-driven CMS, generates I/O on every uncached page request: the MySQL process reads index pages, reads data pages, writes to the binary log, and flushes to disk. A site running on a host with a 2 MB/s I/O limit will experience slower database queries than the same site on a host with a 10 MB/s limit, and the difference is proportional. A complex WooCommerce query that takes 0.3 seconds on a generous I/O budget might take 1.5 seconds on a constrained one.

I/O limits also affect media uploads, backup generation, and plugin installations. A site that uploads a 50 MB video file will saturate a 2 MB/s I/O limit for 25 seconds, during which database queries from other visitors are queued behind the write operation. I/O queuing is a major cause of the mysterious "slow site" complaints that hosting support teams receive, because the slowdown is not correlated with CPU or RAM exhaustion and requires I/O wait metrics to diagnose.

Entry Process Limits

An entry process is a PHP request that has been accepted by Apache or LiteSpeed and is waiting for a PHP worker to become available. Shared hosting plans limit the number of simultaneous entry processes, typically to between 20 and 50. When the limit is reached, additional requests receive a 508 Resource Limit Reached error.

Entry process limits interact with site speed in a feedback loop. When your site is fast, requests complete quickly, workers become free quickly, and the queue never builds up. When your site is slow—because of a slow database query, a slow external API call, or CPU throttling—requests stack up, the entry process limit is hit, and new visitors see error pages. The error pages cause the visitors to leave, which reduces the queue, but the visitors are already gone.

The entry process limit is the primary reason that shared hosting cannot handle traffic spikes. A moderately popular blog post shared on social media might generate 200 simultaneous requests. If your plan allows 30 entry processes, 170 of those requests will see errors, and the 30 that succeed will render slowly because the server is saturated. This is the point at which a site has outgrown shared hosting and should consider a VPS, where entry process limits can be configured upward or eliminated entirely by using a properly tuned web server. For more on how shared hosting refunds work when service is inadequate, see our refund policy comparison.

How Providers Enforce and Disclose Limits

The transparency of resource limit disclosure varies dramatically across providers. Some list exact numerical limits in their knowledge base; others refer vaguely to "unlimited" on the sales page and bury the real limits in the Terms of Service, where they are described as "acceptable use policy constraints" rather than resource limits. At HostingCaptain, we consider transparent disclosure of resource limits a baseline requirement for a trustworthy hosting provider.

CloudLinux, the most widely used shared hosting isolation platform, provides a "Resource Usage" page in cPanel that displays your current and historical resource consumption across all metrics: CPU, RAM, I/O, inodes, entry processes, and IOPS. If your host uses CloudLinux and your cPanel does not show this page, the host has intentionally disabled it—which is a red flag. DirectAdmin, Plesk, and other control panels have equivalent resource monitoring tools, though the naming and location vary.

When a site exceeds a resource limit, most providers follow a three-strike pattern: first violation triggers a throttled state for a few minutes, second violation extends the throttling period, and third violation within a short window results in account suspension. The suspension is usually temporary (a few hours) but can become permanent if resource violations continue after reactivation. Providers that suspend accounts without warning on the first violation are operating with zero tolerance for resource overages, and you should be aware of that policy before you sign up. Understanding when a site has outgrown shared hosting is the topic of our VPS hosting guide.

FAQ

What happens when I exceed my shared hosting CPU limit?

Your site is not taken offline, but PHP processes are throttled—slowed down to reduce CPU consumption. Requests take longer to complete, and if the throttling cannot keep CPU usage within limits, new requests receive 503 or 508 error codes. The throttling resets at the beginning of each 24-hour period.

How many inodes does a typical WordPress site use?

A fresh WordPress installation with a standard theme and 10 plugins uses approximately 15,000–25,000 inodes. A blog with 500 posts, 1,000 images, and a caching plugin can consume 80,000–150,000 inodes. WooCommerce sites with large product catalogs and customer session files can consume 200,000+ inodes. Caching plugins are the largest contributor to inode growth and should be configured with reasonable cache expiration times.

Can I increase my shared hosting resource limits?

Some providers allow individual resource limit upgrades on higher-tier shared plans, but most do not. The standard upgrade path is to move from a basic shared plan to a premium shared plan on the same provider, or to migrate to a VPS where resource limits are configurable. Resource limits on shared hosting are set at the server level and apply equally to all accounts on a given plan tier.

What is the difference between CPU limits and entry process limits?

CPU limits cap total CPU time consumed over a 24-hour period, measured in seconds. Entry process limits cap the number of simultaneous PHP requests allowed at any given moment. A site could have high CPU consumption spread across a small number of requests, or many simultaneous requests each consuming small amounts of CPU. Both limits matter, and exceeding either causes different failure modes.

How can I check my current resource usage on shared hosting?

Log into your hosting control panel (cPanel, DirectAdmin, Plesk) and look for "Resource Usage," "Resource Manager," "CPU and Concurrent Connection Usage," or a similarly named section. On cPanel with CloudLinux, the page shows historical graphs for each resource type. If you cannot find resource usage statistics, contact your provider's support team and ask where they are located.

Is "unlimited" shared hosting really unlimited?

No. "Unlimited" refers to disk space and bandwidth that are not measured in gigabytes but are still subject to inode limits and acceptable use policies. Every shared hosting plan has CPU, RAM, I/O, inode, and entry process limits. The word "unlimited" is a marketing term that describes the absence of a hard gigabyte cap, not the absence of all resource constraints.

Resource limits on shared hosting are not designed to punish you. They are designed to prevent one site from ruining the experience for everyone else on the server. But understanding those limits—reading the actual numbers, monitoring your usage, and anticipating when you will outgrow them—is the difference between a hosting experience that feels reliable and one that feels like the server is working against you. At HostingCaptain, we believe that honest resource disclosure should be the industry standard, and we encourage every hosting buyer to ask for the real numbers before they enter their credit card.