If your site is throwing intermittent 500 errors, slowing down under load, or cPanel is showing a warning on your dashboard, you're likely hitting one of three shared-hosting limits: CPU, memory, or entry processes. Open cPanel and check Resource Usage under Metrics first: it shows 24-hour graphs for all three, so you can see exactly which one is spiking and when. Start plan limits observed on our fra01 server: 100% CPU, 2 GB physical memory, and 40 entry processes, alongside 37,000 IOPS and 60 total processes.
What each limit actually gates
These three limits protect the shared server from any one account using more than its fair share. They're independent of each other, so a site can hit one without coming close to the others.
CPU
This is processor time, measured as a percentage. Heavy plugins, unoptimized database queries, and traffic spikes are the usual causes. Short spikes are normal; a site pinned near the ceiling for minutes at a time is the sign to investigate.
Physical memory
This caps how much RAM all PHP processes on your account can use at once, combined. A single bloated process, like a PHP script parsing a huge file or an import job holding too much in memory, can push the account over the limit even if nothing else is running. See PHP limits explained for how PHP's own per-script memory setting works and where to raise it.
Entry processes
An entry process is any PHP process actively handling a request at a given instant. The limit caps how many can run concurrently, not how many requests you get per day. A traffic spike, a plugin that makes several slow internal requests per pageview, or a cron job overlapping with normal traffic can all push concurrent processes past the cap. When that happens, the server starts queueing or rejecting new requests until a process frees up, which shows up to visitors as slow loads or intermittent errors.
Where these limits show up in cPanel
Shared and WordPress plans use per-account resource caps so no single site can starve its neighbors. The Resource Usage tool under Metrics graphs all three over the past 24 hours, which is the best starting point when you're trying to correlate a slowdown with a specific hour or event.
If you want the full picture of what's counted against your plan, including disk and bandwidth, see checking your hosting resource usage.
Fixing a site that keeps hitting limits
- CPU: look for plugins or themes doing heavy processing on every pageview (image resizing, PDF generation, unoptimized search). Caching cuts CPU load dramatically since cached pages skip PHP execution entirely.
- Memory: check for a single runaway process rather than gradual growth. Bulk imports, large XML/CSV parsing, and some backup or migration plugins are common offenders. Running the job in smaller batches usually fixes it.
- Entry processes: look at what's actually running during Resource Usage's spike windows. Overlapping cron jobs, aggressive bot crawling, or a plugin that fires several slow outbound API calls per request all tie up processes longer than they should.
Across all three, a caching layer helps the most. LiteSpeed Web Server with LSCache runs on all shared and WordPress plans, and WordPress installs come with the LiteSpeed Cache plugin pre-configured plus Redis object cache, so cached requests never touch these limits at all.
When to open a ticket
If Resource Usage shows you consistently pinned near a limit during normal traffic, not just occasional spikes, that's worth a conversation about whether your current plan fits your site's load. Open a ticket from Support in the portal and include a screenshot of the Resource Usage graphs. A real person will look at the pattern with you and can tell you whether the fix is code-level, a plan upgrade, or something else entirely.