The short answer
“Unlimited” is not a capacity measurement
Storage and transfer can be generous while CPU, physical memory, PHP runtime, disk throughput, IOPS, concurrent work, process count, file count or database rules bind first. Compare a limit only after you know its value, unit, scope, time window, measurement surface and enforcement behavior.
Evidence boundary · 13 October 2026
This guide explains how to investigate. It does not claim that one number is enough for every workload, that an HTTP status proves a cause, or that Web Host Lens load-tested a host. Platform examples are labelled and must be verified against your exact plan.
Start here
A five-minute pre-purchase check
- Write down the exact plan, billing term and renewal point.
- Find the technical limits page, acceptable-use terms and a control-panel screenshot.
- Ask which limits apply per request, site, account, package or server—and over what window.
- Ask what happens at each ceiling: throttle, queue, reject, kill, suspend or bill.
- Record absent answers as unknown. Never translate unpublished into unlimited.
For a total-cost view, add renewal, backups, migration and recovery costs with the true hosting cost guide.
Twelve resource families
Similar labels can control different things
CPU / SPEED
A platform may express CPU as a percentage, cores, time or another accounting unit. Saturation may slow work; labels are not comparable without units and scope.
Physical memory
An account or container can have a shared physical-memory ceiling across processes. This is separate from PHP's per-script memory_limit.
PHP runtime and uploads
memory_limit, max_execution_time, post_max_size and upload_max_filesize govern requests or uploads. Effective settings may be host-controlled.
Disk I/O throughput
Throughput describes data moved over time. A cap can throttle reads or writes, while caching and network traffic may be accounted for separately.
IOPS
Input/output operations per second counts operations, not megabytes. Operation size and access pattern make IOPS alone a poor performance prediction.
Entry processes (EP)
CloudLinux defines entries into an LVE; it is not a visitor counter. Its Apache and LiteSpeed implementation details differ, so verify the actual stack.
Total processes (NPROC)
Processes and threads can have a separate ceiling. NPROC is not interchangeable with entry processes.
Workers and concurrency
Simultaneous dynamic work may be queued or rejected. “PHP worker” definitions and behavior differ across hosting stacks.
Inodes
Files and folders consume inodes. Soft and hard thresholds, grace periods and visibility differ; email, logs, caches, backups and staging copies may contribute.
Database controls
Connections, query resources, execution time, database size and storage can bind. Verify both the database engine and provider rule.
Storage and transfer
Disk quota, mail, logs, backups, cache and transfer may have separate rules. Transfer allowance is not network speed or compute capacity.
Operational rules
Cron, SSH, background jobs, backup retention, restore frequency and fair-use policies can constrain a workflow even when a headline allowance looks generous.
Reusable worksheet
Build a limit evidence ledger
Copy this structure into a spreadsheet or support ticket. The sample rows show evidence states, not plan values.
| Control | Value + unit | Scope | Window | Soft / hard | Where measured | At limit | Source + date | State | Recheck |
|---|---|---|---|---|---|---|---|---|---|
| CPU | Unknown | Account? | Unknown | Unknown | Ask for dashboard | Ask whether throttled | No plan source found | Unknown | Before purchase |
| PHP memory | Record effective value | Request / script | Per execution | Configuration limit | Runtime / panel | Correlate error and logs | PHP + host, dated | Verified | After runtime change |
| Inodes | Support answer pending | Account | Current count | Ask both | Panel / quota | Ask exact behavior | Ticket reference | Support-confirmed | At renewal |
Diagnostic restraint
Map symptoms to evidence, not conclusions
| Symptom | Possible evidence | Also check | Do not conclude |
|---|---|---|---|
| Slow dynamic pages | CPU/I/O history, queue or worker metrics, query timing | Cache state, plugins, origin latency, database | That CPU is the cause from latency alone |
| Intermittent 500/503/508 | Timestamped faults, application and web-server logs, support mapping | Deploys, upstreams, maintenance and request type | That a status code identifies one resource |
| Failed upload | PHP upload/post settings, proxy limit, disk and inode headroom | Client timeout, permissions and file type | That storage quota alone failed |
| Backup failure | Disk, inode, process, execution-time and provider backup logs | Exclusions, remote target and retention | That a larger plan fixes recovery design |
| Cannot create files | Inode count, disk quota, filesystem error and permissions | Read-only state and ownership | That an inode limit is proven without the counter |
| Burst-time queueing | Worker/EP history, response percentiles, request timestamps | Cache misses, external calls and database locks | That visitor count equals concurrency |
CloudLinux documents platform-specific cases where CPU or I/O limiting can slow responses, memory or process limits can coincide with 500/503 responses, and its Apache module can return 508 when EP is exhausted. RFC 9110 defines general HTTP semantics; therefore, the status alone is not proof. Correlate it with the account dashboard, fault counters, logs, request type and written support confirmation.
Safe investigation timeline
Test a realistic copy, not production by default
Before
- Confirm terms and provider authorization.
- Prepare a backup and tested rollback path.
- Use staging or a realistic isolated copy.
- Record a normal baseline, cache state and representative request.
During
- Ramp in small steps; change one variable at a time.
- Record timezone and exact timestamps.
- Capture usage, faults, logs and response behavior.
- Abort on errors, unacceptable latency, queue growth, resource faults, data risk or provider warning.
After
- Stop generated traffic and verify recovery.
- Check data integrity and background queues.
- Preserve sanitized evidence; remove test data.
- Compare with baseline before taking action.
Use goal-led test guidance, such as Grafana k6's test-type documentation, only after authorization. This page intentionally provides no “max out the server” recipe. Review recovery preparation first in the backups and recovery guide.
Before paying
Questions sales should answer in writing
- Exact CPU unit, value and account/site scope
- Physical memory versus PHP memory
- I/O throughput and IOPS separately
- EP, NPROC and worker definitions
- Soft and hard inode limits
- Database connection and size rules
- Mail, logs, cache and backups in quota
- Cron, SSH and background-job policy
- Measurement history visible to customers
- Throttle, queue, rejection or suspension behavior
- Higher tier's exact changed constraints
- Renewal, migration and restore costs
For workloads with checkout or account sessions, apply the same questions to the ecommerce hosting guide.
Support escalation pack
Send reproducible evidence—not credentials
- Exact plan/account label and affected site
- Local timezone and exact incident window
- Impacted URLs or operations, without secrets
- Usage/fault screenshots with timestamps
- Short sanitized log excerpts
- Recent deploy, plugin or configuration change
- Cache and CDN state
- Reproduction steps and frequency
- Exact limit, unit, scope and time-window question
- Enforcement behavior and historical peak question
- Written answer and next diagnostic requested
- No passwords, tokens, card data or private keys
Evaluate whether the response is specific and auditable with the hosting support guide.
Browser-local decision aid
Find the first unresolved disqualifier
Ethical commercial next step
Compare plans using your completed ledger
Bring verified values, unknowns, enforcement behavior and full cost into the comparison—then reject any option that fails a critical requirement.
Open the hosting comparator →Affiliate disclosure: some eligible provider links reached from the comparator may earn Web Host Lens a commission at no added cost to you. Compensation does not turn an unknown limit into a verified one or change our evidence rules.
Recheck policy
Evidence expires
Plans, control panels, platform versions and fair-use rules change. Recheck critical limits before purchase, at renewal, after a runtime change and before a traffic event. Preserve a dated copy of the source or support answer. If migration is the safer path, use the website migration guide to plan backups, DNS, mail, validation and rollback.
Frequently asked questions
Hidden hosting limits FAQ
What does unlimited hosting leave unspecified?
It can leave CPU, physical memory, PHP runtime, I/O, IOPS, process, worker, inode, database, backup and fair-use controls unspecified. Verify each control in writing.
Is PHP memory_limit the same as account RAM?
No. memory_limit applies to a PHP script or request, while a platform may separately cap physical memory used across account processes.
Are disk I/O and IOPS interchangeable?
No. I/O throughput measures data moved over time; IOPS counts operations. Workload pattern and operation size affect both.
Is an entry process a visitor?
No. In CloudLinux terminology it is an entry into an account environment, and web-server implementation varies. One visitor can create several requests.
Are entry processes and NPROC the same?
No. Entry processes describe concurrent entries into an environment, while NPROC covers processes and threads. Confirm the host's implementation.
How many PHP workers are enough?
There is no context-free number. Caching, request cost, traffic shape and the provider's worker definition all matter.
What happens when an inode limit is reached?
Behavior depends on the platform and whether the threshold is soft or hard. File creation, uploads, email or backups may be affected, so verify the provider's rule.
Does unlimited bandwidth mean unlimited capacity?
No. Transfer allowance does not prove CPU, memory, storage performance, concurrency or database capacity.
Does a 500, 503 or 508 error prove a resource limit?
No. Correlate the exact timestamp with fault counters, resource history, application and web-server logs, request type and support confirmation.
How should an unpublished limit be compared?
Record it as unknown, not zero or unlimited. Ask for the value, unit, scope, time window, enforcement behavior and historical visibility in writing.
Is it safe to load-test a live shared-hosting site?
The default is no. Use an authorized staging or realistic copy, ramp gradually and stop on errors, unacceptable latency, queue growth, faults, data risk or a provider warning.
When should I upgrade instead of migrate?
Consider an upgrade only when the binding limit is confirmed and the higher plan changes that exact constraint at an acceptable full cost. Opaque or repeated limits and weak recovery paths favor migration comparison.
Sources refreshed 13 October 2026
Primary and provider-specific evidence
No cited platform example establishes a universal recommendation. Verify the exact plan, unit, scope, window and effective enforcement on the date you act.
Release: hidden-hosting-limits-20261013-1