Web hosting resource limits can explain slow pages, failed requests, email problems, and unexpected account suspensions. This guide shows how to track CPU, RAM, storage, inodes, bandwidth, PHP workers, and related warnings, then connect each symptom to a sensible troubleshooting or upgrade decision.
Overview
Every hosting account has limits, even when a plan is advertised as unlimited. Providers may restrict the server resources an account can use, the number of files it can store, the amount of data transferred, or the number of simultaneous processes it can run. The names and thresholds vary between shared hosting, managed WordPress hosting, VPS plans, and cloud platforms, so treat your provider’s control panel and terms as the authoritative reference.
A limit is not automatically a problem. A site can briefly use more CPU during a backup, traffic spike, or scheduled task without needing an immediate upgrade. The important distinction is between a short-lived peak and a repeated pattern. Recurring limits usually indicate that the site needs cleanup, configuration changes, better caching, traffic protection, or more suitable hosting.
Start by recording the warning exactly as it appears. “CPU usage,” “entry processes,” “physical memory,” “inodes,” “disk space,” “monthly bandwidth,” and “PHP workers” describe different constraints. Resolving the wrong one can waste time: deleting old files will not fix an overloaded database query, while upgrading bandwidth will not necessarily solve a PHP memory error.
What to track
Check the resource or metrics area in your hosting control panel, then compare usage with the times when visitors reported a problem. Keep a simple monthly record containing the date, current usage, warning message, traffic event, recent site changes, and action taken.
| Resource | What it controls | Common symptoms | First diagnostic step |
|---|---|---|---|
| CPU | Processing time used by scripts, databases, and server tasks | Slow dynamic pages, timeouts, intermittent 5xx errors | Compare the usage spike with traffic, cron jobs, backups, plugins, and application logs |
| RAM or physical memory | Working memory available to running processes | Memory errors, failed PHP requests, crashed tasks, unstable admin screens | Review application error logs and identify which process or request was active |
| Inodes | The number of files, folders, emails, and other filesystem objects | Uploads fail, mail stops arriving, backups cannot complete, storage appears available but writes fail | Find directories containing caches, backups, logs, mail, or temporary files |
| Disk storage | The total space occupied by website files, databases, email, and backups | Failed uploads, database errors, missing backups, inability to create files | Separate website data, databases, email, and backups to locate the largest category |
| Bandwidth or data transfer | Data sent between the site and visitors, services, or downloads | Throttling, unavailable downloads, unexpected overage notices, account suspension | Check traffic reports, large files, hotlinked assets, media, and unusual requests |
| Entry processes or concurrent requests | Requests being handled at the same time | Queued requests, slow page loads, gateway errors during busy periods | Compare active requests with traffic bursts and slow application operations |
| PHP workers or process limits | The number of PHP requests that can run concurrently | Requests wait in line, checkout or login pages stall, uncached pages are slow | Review cache coverage, slow queries, external calls, and application logs |
Do not confuse storage with inodes. A site may use modest disk space but contain hundreds of thousands of small files from cache directories, image variants, email folders, or repeated backups. Conversely, one large video can consume substantial storage and bandwidth while using only one inode.
Also record application-level limits. WordPress sites may encounter PHP memory, upload-size, execution-time, or database-connection limits even when the hosting account dashboard looks healthy. A control panel warning is useful evidence, but server and application logs often identify the failing operation more precisely.
Cadence and checkpoints
A monthly review is suitable for most small sites. Record resource usage, available storage, inode count, backup size, database size, and any alerts. Look for direction rather than a single number: a steadily growing upload directory or database deserves attention before it reaches the plan limit.
Run a more detailed review each quarter. Test important pages, forms, login screens, checkout flows, scheduled tasks, and email delivery. Check whether backups complete and whether old backups are being retained in the hosting account. Review recently installed plugins, themes, extensions, tracking tools, and integrations because new features often change request volume or processing requirements.
Use additional checkpoints after a traffic campaign, product launch, migration, major software update, or content import. Check the account during the event and again afterward. A temporary spike may be expected, but persistent usage can reveal an inefficient query, uncached page, runaway task, or unexpectedly popular file.
When possible, capture the time zone and time window used by the hosting dashboard. Resource graphs may be aggregated, and a daily average can hide short peaks that caused a timeout. Keep screenshots or exported reports when contacting support so the provider can compare the alert with server-side records.
How to interpret changes
CPU or PHP usage rises
First compare the timing with traffic and scheduled work. Backups, search indexing, image processing, security scans, imports, and cron jobs can create predictable peaks. If the rise happens on ordinary page views, test caching and examine slow queries or repeated external requests. Disable or isolate recently added extensions only after creating a backup and using a safe maintenance process. If the same workload repeatedly reaches the limit after optimization, a VPS, cloud plan, or higher-tier managed platform may be more appropriate than continuing to remove features.
RAM, entry processes, or PHP workers are exhausted
These limits often appear together when requests remain active for too long. Review uncached pages, admin tasks, database queries, API calls, and large imports. Reduce unnecessary concurrent jobs and ensure scheduled tasks are not running more often than required. A larger memory allocation alone may not solve a slow query or blocked external service. Ask the host whether the plan can increase workers or process capacity, and whether the application is compatible with that change.
Inodes or storage approach the limit
Use the file manager, command line, or hosting storage report to sort usage by directory. Common candidates include old backups, cache files, debug logs, temporary archives, unused staging copies, and abandoned email. Delete only files you can identify safely; preserve current backups and follow the application’s cleanup procedure. Move archives away from the live hosting account when appropriate. If the site genuinely requires many files, confirm that the next plan supports the needed inode count rather than focusing only on disk capacity.
Bandwidth increases unexpectedly
Check whether the growth comes from legitimate visitors, downloadable assets, video, image-heavy pages, bots, or hotlinking. Review web-server access logs and analytics together, because they answer different questions. Optimize large assets, use suitable caching, and consider a content delivery service where it fits the site. Do not assume a bandwidth upgrade will resolve slow server processing: transfer capacity and CPU capacity are separate constraints.
5xx errors or email failures appear
Note the exact error code and time. A 500 or 503 response can result from application errors, exhausted processes, memory limits, maintenance, or a provider-side incident. Email failures may reflect full storage, inode exhaustion, mailbox quotas, DNS configuration, or sending limits rather than website CPU usage. Check logs, mailbox capacity, DNS records, and the provider status page before changing several settings at once.
When an account is suspended, contact hosting support promptly and request the resource category, relevant time window, and affected process if available. Ask what temporary mitigation is permitted. Do not repeatedly refresh a failing site or launch untested cleanup scripts, as both can make an incident harder to diagnose.
When to revisit
Revisit this audit monthly, after a significant traffic change, and whenever the site adds plugins, products, media, mailboxes, or automated jobs. Repeat it before renewal or migration so you can compare the actual resource profile with the next plan’s documented allowances. A hosting comparison should consider renewal cost, support, backup design, process limits, and upgrade paths—not just storage or advertised bandwidth.
Use this practical sequence at each review:
- Record current CPU, memory, inode, storage, bandwidth, process, and PHP-worker readings.
- List warnings, error codes, slow pages, failed jobs, and email symptoms with their timestamps.
- Compare changes against traffic, deployments, extensions, backups, and scheduled tasks.
- Remove identifiable waste, improve caching or asset delivery, and retest one change at a time.
- Contact the provider when the cause is unclear or the same limit returns after cleanup.
- Upgrade or migrate when the site’s normal workload consistently exceeds the plan’s practical capacity.
For related recurring checks, use the web hosting maintenance checklist and the website speed and hosting performance checklist. If resource pressure leads to a move, document the current limits and follow a tested WordPress migration checklist rather than treating a new host as a substitute for diagnosis.
