Entry process and I/O limits are two of the quieter resource limits on shared hosting that cap how much a single account can do at once. The entry process limit caps how many of your scripts can run simultaneously (concurrent processes), while the I/O limit caps how fast your account can read and write data to disk. Both exist to keep a shared server fair and stable, and both can cause a busy or heavy site to slow down or briefly error even when bandwidth, storage, and memory look fine.
This guide explains what entry processes and I/O limits are, why hosts set them, what happens when you hit them, and how to keep a site comfortably within them.
Did you know?
Entry process and I/O limits are why a shared site can hit a wall during a traffic burst while its bandwidth and storage sit almost unused. They cap concurrency and disk activity, not total data.
What the entry process limit is
The entry process limit caps how many of your account’s processes (scripts) can be running at the exact same moment. Each dynamic request that is actively executing counts as an entry process, so this limit is about concurrency — how many things your site is doing simultaneously — not how many requests you get over time.
It is a short-lived, moment-to-moment count. A request enters, runs, and finishes in a fraction of a second, freeing the slot. Problems arise only when many requests try to run at the very same instant, which happens during traffic bursts or when scripts run slowly and pile up.
What the I/O limit is
The I/O (input/output) limit caps how fast your account can read from and write to the disk — the rate of data movement to and from storage, usually measured in megabytes per second. It governs disk throughput rather than how much you store.
Every time your site reads files or database data, or writes logs, caches, or uploads, it uses I/O. A site that constantly hammers the disk — heavy, uncached database activity, for example — can hit its I/O limit, at which point disk operations are throttled and the site slows until activity eases.
Why hosts set these limits
Both limits exist to keep shared servers fair and stable. On shared hosting, many accounts share one machine, so without limits a single busy or badly behaved account could monopolise the processors or the disk and slow everyone else down.
Entry process and I/O limits ring-fence each account’s share of concurrency and disk activity, so one site’s spike does not drag down its neighbours. They are a normal, sensible part of how shared hosting stays affordable and reliable for everyone — and ordinary sites rarely brush against them.
What happens when you hit them
Hitting either limit causes temporary, self-correcting symptoms rather than a full outage:
- Entry process limit reached: new requests briefly queue or return a temporary error (like a 508) until a slot frees up.
- I/O limit reached: disk operations are throttled, so the site slows until activity drops back.
- Common trigger: traffic bursts or heavy, uncached activity.
- Usually brief: symptoms ease as the surge passes.
- Bandwidth and storage look fine: the limit is concurrency or disk rate, not data volume.
Pro Tip
If your site occasionally shows a 508 ‘resource limit reached’ error or slows during bursts, entry process or I/O limits are a likely cause — not bandwidth. Caching and optimisation usually fix it before an upgrade is needed.
How to stay within these limits
The best defence is caching. Cached pages are served quickly without running scripts or hammering the disk, so they consume far fewer entry processes and much less I/O. Strong caching alone keeps most sites comfortably within both limits even during busy spells.
Beyond caching, keep the site efficient: trim heavy or poorly built plugins, optimise the database so queries are quick (fast scripts free their process slot sooner and read less from disk), keep PHP current, and avoid unnecessary background tasks. A lean, well-cached site rarely troubles these limits.
When to consider an upgrade
If a site regularly hits entry process or I/O limits despite good caching and optimisation, it has genuinely outgrown its shared plan’s share of resources. That is the signal to move up — to a higher shared tier with more allowance, or better, to a VPS or cloud plan with guaranteed, dedicated resources that are not shared with other accounts.
On a VPS or cloud plan these shared-hosting-style limits largely fall away, replaced by the guaranteed CPU, memory, and I/O of your own environment. So the path is clear: optimise and cache first, and upgrade to dedicated resources when a busy, dynamic site consistently needs more than a shared plan can fairly give.
Want hosting with generous, honest specs?
Hostinger’s plans come with fast NVMe storage, ample resources, free SSL, and clear limits — no fine-print surprises. From a few dollars a month; use code PROTIPS for the reader discount.
FAQs
What are entry process and I/O limits in hosting?
They are shared-hosting resource limits. The entry process limit caps how many of your scripts can run at the same moment (concurrency), while the I/O limit caps how fast your account can read and write to disk. Both keep a shared server fair and can slow a busy site even when bandwidth and storage are fine.
What is the entry process limit?
It caps how many of your account’s processes (scripts) can run at the exact same time — a concurrency limit, not a total request count. Each actively executing dynamic request counts as one. Problems arise only when many requests try to run at the same instant, such as during traffic bursts.
What is the I/O limit?
The I/O (input/output) limit caps how fast your account can read from and write to disk, usually in megabytes per second. It governs disk throughput, not storage size. A site with heavy, uncached disk activity can hit it, at which point disk operations are throttled and the site slows.
Why do hosts set entry process and I/O limits?
To keep shared servers fair and stable. Many accounts share one machine, so without limits a single busy account could monopolise the processors or disk and slow everyone else. These limits ring-fence each account’s share of concurrency and disk activity so one spike does not affect neighbours.
What happens when I hit these limits?
Hitting the entry process limit makes new requests briefly queue or return a temporary error (like a 508) until a slot frees; hitting the I/O limit throttles disk operations so the site slows. Both are usually brief, triggered by traffic bursts or heavy activity, and ease as the surge passes.
How do I avoid hitting entry process or I/O limits?
Cache aggressively — cached pages skip scripts and heavy disk activity — and keep the site efficient with lean plugins, an optimised database, and current PHP. If a site regularly hits these limits despite that, it has outgrown shared hosting and should move to a VPS or cloud plan with dedicated resources.
The bottom line
Entry process and I/O limits are the quiet concurrency and disk-rate caps on shared hosting: the entry process limit governs how many of your scripts run at once, and the I/O limit governs how fast you read and write to disk. Both keep shared servers fair, and both can slow a busy or heavy site — often with a brief 508 error or a slowdown during bursts — even when bandwidth and storage look untouched.
The fix is usually caching and optimisation, which dramatically reduce both process and disk demand, keeping most sites comfortably within the limits. When a dynamic, busy site consistently hits them despite that, it has outgrown shared hosting — the moment to move to a VPS or cloud plan with guaranteed, dedicated resources where these shared limits fall away.
When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. Entry process and I/O limits cap concurrency and disk rate — caching keeps most shared sites within them.