Hosting CPU Limits Explained: What Slows a Site Before Storage Runs Out
A hosting plan can have plenty of storage left and still run out of room to do work. CPU, memory and concurrent-process limits govern how many requests the account can handle and how quickly. A busy checkout, a heavy WordPress plugin or an uncached traffic spike can expose them before you use even a fraction of the advertised disk space.
What does a CPU limit actually mean?
CPU is the processing time available to run your website’s code. On some shared-hosting systems a plan is assigned a share of a core or a CPU speed limit; other hosts describe cores, CPU seconds or a proprietary resource allowance. Those labels are not interchangeable. CloudLinux, a platform used by some hosts, documents separate controls for CPU speed, physical memory, disk input/output and entry processes. That describes one implementation, not a promise that every host uses CloudLinux.
Think of an uncached WordPress page as an order placed with the server. PHP runs, the database may be queried, plugins do their work and the response is assembled. Page caching can avoid much of that work for repeat public views. Cart pages, logged-in sessions, scheduled jobs and admin tasks often need processing even when the homepage is cached. A plan promising “unlimited bandwidth” has not promised unlimited computing.
CPU, RAM and entry processes: three different bottlenecks
| Resource | What it limits | What to ask |
|---|---|---|
| CPU | How quickly server-side work can be processed | Is the allowance a speed cap, a number of cores, or usage over time? |
| Physical memory | Memory used by running processes | What happens when several PHP jobs need memory at once? |
| Entry processes or PHP workers | How many dynamic requests can be handled concurrently | Is the listed figure per account or per website? What happens at the limit? |
| Disk I/O and IOPS | Data throughput and file operations | Are there separate limits during backups, imports or heavy database activity? |
Concurrency is particularly easy to misunderstand. Ten simultaneous visitors reading cached pages need not produce ten expensive PHP jobs. One import, cron job or plugin task may consume substantial resources with almost no visitors. CloudLinux’s documentation defines entry processes around concurrent entries into an account’s execution environment, including dynamic web work. It is not a visitor counter.
What does hitting a limit look like?
It depends on the provider and the resource. A page might get slower, a dynamic request may fail, or the host may show a 503 error. Hostinger says reaching plan limits for processes or RAM can lead to a 503, and directs customers to resource graphs to confirm the cause. A 503 by itself is not a diagnosis: maintenance, an application failure and other conditions can also cause one. CloudLinux documents a 508 response for some entry-process failures in its own environment. Do not assume either code proves the same root cause on every host.
A five-minute investigation before paying for an upgrade
- Record the time, URL and type of failure: a public cached page, checkout, dashboard or a scheduled task.
- Open the host’s resource-usage panel and compare the CPU, memory, process and I/O graphs with that time. Hostinger, for example, puts aggregate plan usage under Hosting plan → Resources Usage.
- Look for a repeatable spike: a backup, malware scan, image import, search bot or a plugin doing work on every request.
- Check page caching and the application logs. Do not disable security or backups just to make a graph look prettier.
- Ask support for the exact limit reached, its duration, and a plan comparison in writing. If a real workload needs more headroom, price the upgrade at renewal as well as today.
If you cannot see the metric or its unit, ask before buying. “More powerful” is not a resource specification. Also distinguish a steady capacity problem from a broken plugin: buying a larger plan can hide inefficient code for a while, but the bill rises faster than the fix.
Who should care most?
A small cached brochure site may never notice these limits. A WooCommerce checkout, membership area, high-traffic campaign or agency account with several WordPress sites is more likely to encounter dynamic concurrency. Compare the resources and support for the actual workload. Our shared versus VPS versus cloud guide explains when a different hosting model makes sense, while our speed and uptime guide covers the other moving parts. For plan cost, use the renewal-cost calculator.
Before you choose a plan
Ask for the CPU unit, memory allowance, concurrent-process limit, I/O limit, reporting window, failure behavior and upgrade price for the exact tier. Save the answer. A large storage number is nice; a working checkout is nicer.
Sources checked September 25, 2026: CloudLinux resource-limit documentation, Hostinger plan parameters, Hostinger resource-usage guide and Hostinger limit troubleshooting. Provider limits and dashboards can change; verify the chosen plan.