Shared hosting plans advertise unlimited storage and bandwidth, but they enforce resource limits in ways the marketing doesn't mention. Understanding what limits exist and what happens when you hit them lets you manage your site without unexpected surprises, and gives you the information you need to decide when it's time to upgrade.
Most shared hosts use CloudLinux to enforce per-account resource limits. CPU is typically capped in terms of CPU seconds per time period, your account can use, say, 100 CPU seconds per minute. If your site generates more PHP processing than the limit allows, requests are queued or returned with a 508 error (Resource Limit Is Reached). This is the most common resource limit visitors actually see.
It manifests as slow loading or error pages during traffic spikes, even if the rest of the server is working fine. The root cause is always the same: too many PHP processes competing for the CPU allocation your account is allowed. A sudden spike, a viral post, a product launch email to a large list, a Reddit feature, can trigger this on sites that normally run without issue.
The fix depends on the source of the load. Server-level caching (LiteSpeed Cache) is the most effective solution: cached pages are served without invoking PHP at all, so they don't consume CPU allocation. If you're already caching but hitting limits, you've genuinely outgrown your current plan and should look at a higher shared tier or a VPS.
Each PHP process on your account is constrained by a memory limit (typically 256–512MB on modern hosts). If a single PHP request, a WooCommerce product import, a large page with many plugins, a complex database query, exceeds this limit, it terminates with a fatal error. WordPress typically surfaces this as "Allowed memory size of X bytes exhausted."
You can raise the PHP memory limit via cPanel's PHP settings up to the maximum the host allows. Adding define('WP_MEMORY_LIMIT', '512M'); to wp-config.php instructs WordPress to request up to that amount, but the server setting is the hard ceiling. If your host allows a maximum of 256MB and you set WP_MEMORY_LIMIT to 512M, the effective limit is still 256MB.
Common culprits for memory exhaustion: plugins that load all post metadata at once, WooCommerce with large product databases, poorly optimised theme frameworks that bootstrap excessive libraries on every request, and anything that generates large image manipulation operations (resize, compression) in PHP rather than offloading to a dedicated service.
Shared hosts limit the number of simultaneous PHP processes per account. If you receive a burst of traffic and each visitor's request spawns a PHP process, you can exhaust your concurrent connection limit. Visitors after the limit hit either wait in a queue (causing slow load times) or see an error immediately.
This is why caching is so important on shared hosting. A cached page served by LiteSpeed or a similar web server doesn't spawn a PHP process, it's served directly from the cache layer. Cached traffic doesn't consume your PHP worker allowance. On a site serving 90% of its traffic from cache, the PHP worker limit effectively applies only to the 10% of requests that need dynamic processing.
PHP workers are often not disclosed in plan marketing. Ask your host how many PHP workers your plan includes. Some plans allocate as few as 2–4, meaning only 2–4 simultaneous uncached requests can be processed. For a low-traffic site with good caching, this is fine. For anything with real concurrent usage, it's a hard ceiling that manifests as queuing delays.
MySQL on shared hosting has connection limits per account. WordPress opens a database connection for each PHP request that isn't served from cache. Sites with many concurrent visitors and no page caching can exhaust database connections, causing "Error Establishing a Database Connection." This error is alarming but not always server-side, it can also be triggered by incorrect credentials in wp-config.php, but the concurrent connection scenario is the typical cause on a live, previously-working site.
Enabling a caching plugin dramatically reduces database connection usage and is the first mitigation step before considering a plan upgrade. If you're already caching and still hitting database connection errors, the issue is likely very high concurrent logged-in user traffic (WooCommerce checkouts, membership sites) where sessions bypass the page cache by design.
An object cache (Redis or Memcached) can also reduce database load significantly. Rather than querying the database for the same data on every request, an object cache stores query results in memory. Some shared hosts offer Redis as an add-on. If yours doesn't and you're frequently hitting database limits, it's another reason to consider a VPS where you can configure Redis yourself.
Many shared plans advertise "unlimited bandwidth," which requires careful reading. Truly unlimited bandwidth is common, but what varies is how the host reacts to genuinely high-volume traffic. Some hosts throttle bandwidth after a certain threshold. Others don't throttle but will contact you if your account is generating disproportionate traffic relative to what your plan is designed for.
The realistic scenario: a WordPress site with properly optimised images, good caching, and a CDN handling static assets will rarely create bandwidth pressure on a shared plan. Problems arise on sites serving large files (video, large PDFs, downloadable software) directly from the hosting server. Move large file downloads to cloud storage, Amazon S3, Backblaze B2, or a CDN origin, and your bandwidth usage stays well within shared hosting norms.
Unlimited storage plans have two catches. First, acceptable use policy clauses prohibit using shared hosting for file storage, backups, or file hosting that doesn't primarily serve a website. A WordPress site with 50GB of uploaded media files is technically within the storage limit but may trigger fair use policy enforcement. Use cloud storage for large media libraries.
Second, inode limits are the more practical constraint. An inode is a file system entry, every file, folder, and symlink on your account counts as one inode. Plans often cap inodes at 100,000–250,000. A standard WordPress install with a few plugins and themes uses maybe 20,000–30,000 inodes. Add a media library with thousands of images (each with multiple size variants), several plugin directories, and a theme with many templates, and you can approach inode limits well before running out of actual storage space.
The pattern of consistently hitting shared hosting limits, frequent 508 errors, slow load under moderate traffic even with caching, database connection issues, signals it's time to move up. The next step is usually a higher shared tier with more PHP workers and CPU allocation, or a VPS with dedicated resources.
A VPS removes the noisy neighbour problem entirely and gives you a fixed allocation of RAM and CPU that isn't shared with other accounts. For a WordPress site at the point where it's consistently stressing shared hosting limits, a basic 2–4GB VPS is often the right call. The cost difference is modest (typically £10–30/month more than shared) and the performance gain is significant. Managed VPS options remove the server administration overhead if you don't want to manage the stack yourself.
HostBible shared plans include PHP memory limits sized for WordPress, CloudLinux resource management, and LiteSpeed caching to keep you well within limits on normal traffic.
View Hosting Plans