Your Fast Hive shared hosting account has its own guaranteed slice of the server - CPU, memory, disk throughput and concurrent processes - and its own ceiling on each. Every machine is capped at around 50 accounts against an industry average of 400 or more, so your neighbours cannot take your resources. But your own site can still hit its own ceiling, and when it does the symptoms look exactly like "the server is slow". This guide shows you how to read those limits, what each one actually means, and what to do when you reach one.
Log in to cPanel and look at the Statistics panel down the right-hand side of the home screen. Every limit on your specific plan is listed there with its current usage. For history and diagnostics, open Metrics → Resource Usage.
The limits, and what each one really means
A typical shared plan shows figures in this shape. Yours may differ - read your own Statistics panel rather than assuming.
| Limit | Example value | What it controls |
|---|---|---|
| CPU Usage | 0 / 100 | Processor time available to your account, as a percentage of your allocation. Sustained 100% means pages queue behind each other. |
| Entry Processes | 0 / 20 | How many PHP requests can be executing simultaneously. The most commonly hit limit, and the least understood - see below. |
| Physical Memory Usage | 0 bytes / 1 GB | RAM your processes may consume together. Exceeding it kills the process, producing a 500 error or a white screen. |
| IOPS | 0 / 1,024 | Disk operations per second. Hit by unindexed database queries and by scripts touching thousands of small files. |
| I/O Usage | 0 bytes/s / 10 MB/s | Disk throughput. Reached by large file transfers, backup generation and video serving. |
| Number Of Processes | 0 / 100 | Total processes your account may have open, including cron jobs and shell sessions. |
| Disk Usage | 10.56 GB / ∞ | Files, mail and databases together. Unlimited on the Ultimate plan. |
Entry Processes: the one that surprises people
Entry Processes is not "visitors". It is how many PHP requests are being executed at the same instant. A page that renders in 200 milliseconds occupies one entry process for a fifth of a second, then releases it. On a limit of 20, that comfortably serves a great many visitors an hour.
The problem is slow pages. If a page takes 8 seconds to build, each visitor holds an entry process for 8 seconds - and 20 simultaneous visitors is now enough to fill the ceiling. Once full, further requests are refused with a 508 Resource Limit Reached error.
Reading the Resource Usage tool
- In cPanel, open Metrics → Resource Usage.
- The Dashboard tab gives you the headline: either "Your site had no issues in the past 24 hours", or a summary of which limits were reached.
- Click DETAILS, or the Current usage tab, to see live figures against each limit.
- The Snapshot tab is the valuable one when something went wrong. It captures what your account was actually doing at the moment a limit was hit - which processes were running and what they were executing.
- Options lets you configure notifications so you hear about a limit being reached rather than discovering it from a customer.
If the Dashboard reports no issues in the past 24 hours, resource limits are not your problem - look elsewhere, starting with Metrics → Errors.
Matching the symptom to the limit
| What visitors see | Usually means | First thing to try |
|---|---|---|
| 508 Resource Limit Reached | Entry Processes full | Enable caching; find and fix the slow page |
| Site fine at night, slow at peak | CPU at its ceiling under load | Caching, then audit plugins |
| Random 500 errors or white screens | Memory limit exceeded | Raise the PHP memory limit; find the memory-hungry plugin |
| Admin area crawls, front end is fine | IOPS - heavy database reads | Clean up the database; add indexes |
| Everything stalls while a backup runs | I/O throughput saturated | Schedule backups for quiet hours |
| Spikes at exactly the same time each hour | A cron job or scheduled task | Review Cron Jobs; reduce frequency |
Bringing usage down, in order of impact
- Turn on caching. A cached page is served without running PHP or touching the database at all. This routinely cuts CPU and entry process usage by an order of magnitude. Use one caching plugin, never two.
- Find the slow page. Use your browser's Network tab and watch time-to-first-byte. Fixing one slow template often fixes the whole account.
- Audit plugins and extensions. Deactivate, measure, repeat. Related-posts widgets, live visitor counters, on-the-fly image resizers and statistics plugins are frequent offenders.
- Clean the database. Years of post revisions, expired transients and orphaned metadata make every query more expensive. Use phpMyAdmin or a maintenance plugin.
- Move heavy jobs off peak. Imports, exports, backups and report generation belong at 03:00, not midday.
- Reduce cron frequency. A task running every minute that only needs to run hourly is 60 times the load for no benefit.
- Compress images. Large images consume I/O on every single request.
- Block bad bots. Aggressive scrapers can consume a meaningful share of your allocation. Use Security → IP Blocker once you have identified them in Metrics → Visitors.
When you have genuinely outgrown the plan
Sometimes the site is efficient and simply popular. Upgrade when, after caching is in place and the obvious offenders are gone, you still see:
- CPU sitting at its ceiling for sustained periods rather than in brief spikes.
- Entry processes filling repeatedly at normal traffic levels with fast pages.
- Memory limits being hit by a legitimately heavy application.
Moving up a shared tier is applied to the same account - no migration and no downtime. If you need dedicated vCPU and RAM that nothing else can touch, a VPS is the next step, and our team handles the move.
Troubleshooting
| Symptom | Cause and fix |
|---|---|
| 508 error appears for you but the site works for others | Entry processes were briefly full. It clears on its own within seconds. Persistent 508s need the fixes above. |
| Resource Usage shows no issues but the site is slow | Not a resource limit. Look at unoptimised images, render-blocking scripts, or a slow external API the site calls on every page. |
| Usage spikes with no visitors | Bots, a cron job, or a compromised account sending mail. Check Metrics → Visitors and Cron Jobs, then Virus Scanner. |
| Disk usage climbing steadily | Open Files → Disk Usage to see which directory is growing. Usually old backups, logs, or a mailbox nobody empties. |
| Memory errors only when updating or importing | A one-off peak, not a sizing problem. Raise the PHP memory limit temporarily in MultiPHP INI Editor. |
| Cannot tell which plugin is responsible | Use the Snapshot tab in Resource Usage - it records what was executing when the limit was hit. |
Frequently asked questions
Can another customer's website slow mine down?
No. Each account has its own guaranteed CPU, memory and disk I/O floor, and a neighbour hitting their ceiling is throttled at their own limit rather than borrowing from yours. We also cap each machine at around 50 accounts, well under the industry norm.
Does hitting a limit get my account suspended?
No. Limits throttle, they do not suspend. Requests are queued or refused with a 508 until usage falls back, then everything continues normally.
My plan says unlimited - why are there limits at all?
Unlimited refers to storage, bandwidth, databases, email accounts and websites. CPU, memory and concurrent processes are finite on any physical machine, and publishing the numbers is how we keep the platform fast for everybody.
How long is the data in Resource Usage kept?
The dashboard focuses on the last 24 hours, with longer history available in the detail views. Investigate promptly while the snapshot of the incident is still there.
Will upgrading my plan definitely fix a 508 error?
Only if the cause is genuine traffic. If a single slow query or plugin is holding processes open, a bigger plan buys you a slightly higher ceiling to hit. Fix the cause first, then upgrade if you still need to.
Do email and cron jobs count against these limits?
Yes. Cron jobs consume entry processes, CPU and memory like anything else, which is why an over-frequent cron can take a site down on its own.
