Your Site Is Slow, CPU and Memory Are Fine: How to Tell If You’re Being Disk-I/O Throttled 

A slow site with a clean resource graph is the most frustrating problem on shared hosting, because every diagnostic you can find assumes something is broken and nothing is. The CPU chart is flat. Memory is well under the cap. There is no 508 error to paste into a search box. The site is simply slow while traffic is heavy and fast again twenty minutes later. That pattern has one specific cause that almost nothing in the hosting literature covers: you are being throttled on disk I/O. This post shows how to confirm it from your own cPanel in about five minutes, what inside a WordPress site actually generates the reads and writes, and how to tell a problem you can tune away from a ceiling you have genuinely outgrown.

Why a Disk I/O Limit Never Shows You an Error

A disk I/O limit does not fail your request — it delays it. That single difference is why this problem survives every checklist. Most account limits on cPanel shared hosting are enforced by refusal: ask for more than you are allowed and the server declines, which gives you a status code, a log line and something to look up. The disk limits are enforced by delay instead, and a delay leaves no trace anywhere except one column most people never open.

The Two Limits That Throttle and the Four That Fault

CloudLinux, which enforces per-account resource limits on the great majority of cPanel shared hosting, applies six ceilings to your account. Its published limits documentation names them: SPEED for processor allocation, PMEM and VMEM for memory, NPROC for total processes, EP for concurrent entry processes, and then IO and IOPS for the disk. The first four announce themselves. Exhaust your entry processes and you get a 508; exhaust physical memory and PHP dies with a fatal error. Our diagnostic tree for 503 and 500 resource errors walks those four in detail, and every one of them ends in a visible failure. The last two do not.

What “Put to Sleep” Means for a Page Load

CloudLinux is unusually direct about the mechanism. Its documentation states that when the limit is reached, the processes are throttled — put to sleep — so that they cannot exceed the limit and yet “don’t stop working, nor getting killed – they just work slower when the limit is reached.” A sleeping PHP process is not a failed request. It is a request that will finish, eventually, having produced no error for anyone to find. There is a sting in this, though, and it is the reason the two halves of the diagram below are connected: a request asleep on the disk is still holding its entry process. Throttle hard enough for long enough and the concurrency ceiling fills with sleeping requests, and you finally get a 508 whose actual cause was the disk all along.

Disk I/O Throughput and IOPS Are Two Separate Ceilings

These are not two names for one thing, and confusing them sends you after the wrong fix. Throughput is a volume: KB/sec, how much data may move between your account and the disk. IOPS is a count: how many distinct read and write operations you may perform each second, irrespective of how small each one is. cPanel’s own guidance on high disk I/O puts the underlying idea plainly — disk I/O “describes how long the read and write operations require on a hard disk.” A backup archive is a throughput workload: few operations, enormous volume. WordPress is the opposite, and that asymmetry decides which of your two ceilings you hit first.

How to Confirm Disk I/O Throttling in cPanel in Five Minutes

Open cPanel, go to Logs, then Resource Usage. Everything this section asks for is on that one screen, and it is available on every plan — you do not need shell access, a monitoring plugin or a support ticket to answer the question.

Read the Faults Column, Not the Usage Graph

The usage chart is the wrong number to read, and it is the number everyone reads. Usage tells you how close you came; a fault tells you that the ceiling was reached and enforced. An account can sit at ninety percent of its limit all day without a single fault and be perfectly healthy. One fault means processes were slept. The CloudLinux end-user documentation confirms what the screen exposes: charts for CPU, memory, Input/Output, IO operations, entry processes and processes, plus a Current Usage table carrying a row for I/O and a separate row for IO operations, each showing usage, limit and a fault count. Filter to the hour or the minute of the slowdown. A 24-hour average will hide a ten-minute stall completely, which is exactly how this problem stays invisible for months.

The Snapshot Tab Shows Which Process Was Asleep

Faults tell you that you were throttled; the Snapshot tab tells you what you were doing at the time. When an account hits a limit, the statistics daemon captures a server snapshot containing the process list and, on cPanel, the database and HTTP queries that were running at that moment. Choose the date and the snapshot matching a fault and you will usually be looking directly at the cause — a nightly archive, a scanner walking the filesystem, an unindexed query, or a burst of checkout traffic. This is the step that turns a capacity reading into a specific thing you can change.

The Reading That Rules Disk I/O Out

Zero faults on both disk rows across the whole slow window is a real result and worth as much as a positive one. It means the ceiling was never reached, the slowness lives in the application or the network rather than in your allocation, and no plan upgrade will touch it. Our knowledge base covers the next fork in that road in how to tell whether a slow site is the server or the site. Rule the disk in or out first, though, because it is the one limit that produces no evidence anywhere else.

The AHosting Disk I/O and IOPS Ladder

Most hosts do not publish these numbers at all, which is why sizing against them is so rarely possible. AHosting does. The table below is the same allocation shown on the shared web hosting plans, and it is the AHosting Disk I/O and IOPS Ladder referenced throughout this post.

Plan	Disk I/O	IOPS	Entry processes	Memory	CPU
Bronze	10 MB/s	1,024	30	2 GB	2-core limit
Silver	20 MB/s	2,048	40	3 GB	3-core limit
Gold	30 MB/s	3,072	50	4 GB	4-core limit

What 10 MB/s Actually Serves

Throughput is a rate rather than a monthly quota, which changes how you reason about it. Ten megabytes per second is roughly ten thousand kilobytes every second, sustained, forever — so an ordinary cached HTML page of sixty kilobytes leaves room for well over a hundred such responses per second before volume becomes the constraint. Almost no shared site reaches that. The number that matters is what happens when something large runs alongside your visitors: a full-account backup, a large upload, a video file being read end to end. Those compete for the same rate, and they are the reason a site can be slow at 2am for reasons that have nothing to do with traffic.

Why the IOPS Ceiling Usually Binds First

Operations run out long before megabytes do on a database-driven site. An uncached WordPress request reads a large number of small things: PHP files for core, the theme and every active plugin, then the rows behind the page. Each is an operation and almost none of them is large. At Bronze you are allowed 1,024 of those per second across the whole account, which sounds generous until you multiply it by concurrent uncached requests. Our analysis of the server-side factors no plugin can fix covers the storage tier underneath this; the ceiling here is separate from the hardware and applies no matter how fast the underlying disk is. A fast NVMe array you are throttled against is still a throttle.

The Five Things That Generate WordPress Disk I/O

Before changing a plan, find out what is spending the allocation. In practice almost all of it comes from five places, and they are listed here in roughly the order they turn up in real Snapshot output.

Uncached HTML, and What LiteSpeed Cache Changes

Serving a page from cache replaces a few hundred operations with one. An uncached request executes PHP, reads the file tree and runs the queries behind the page; a cached request reads one prepared file and returns it. On AHosting a cached page also consumes zero entry processes, so caching relieves both ceilings at once, which is why it is the first fix rather than a later one. The limit of that relief matters too: pages that cannot be cached never get it. Anything personal to the visitor — cart, checkout, account, any logged-in view — runs in full every time, which is exactly why checkout must be excluded from the cache deliberately, and why stores feel this ceiling far more sharply than brochure sites do.

The Database: Revisions, Transients and Autoloaded Options

Database writes are disk writes, and more of them than people expect. Every committed change is also written to a transaction log before it lands in the table, as MariaDB’s documentation of the InnoDB redo log describes. Three things dominate on a typical site. Post revisions accumulate without limit unless you cap them, which you can do with a single constant documented in the wp-config reference — we measured the effect of that in our post on limiting WordPress post revisions. Expired transients pile up when nothing clears them. And autoloaded options are read on every single request, so a bloated options table taxes every page you serve rather than one.

Backups, Cron and Scanners Running Inside Your Own Limit

This is the category that surprises people, because these jobs feel like infrastructure rather than site traffic. They are not. A backup plugin archiving your whole account, a security scanner walking every file, an SEO plugin rebuilding a sitemap and WordPress’s own scheduler all run as your account, inside your allocation, competing with your visitors for the same operations per second. Worse, the default scheduler fires on visitor requests, so the heaviest jobs can land at your busiest moment. Our measured write-up on disabling WP-Cron and replacing it with a real cron job covers moving that work to a quiet hour, which is often the single cheapest change available here.

Logs, Sessions and the Files Nobody Watches

Small, constant writes are easy to overlook because no single one is expensive. PHP session files are written per visitor per request. Debug logging left enabled after a support session appends on every notice. Object-cache and page-cache files are written as well as read. Individually these are trivial; together, on a busy account, they form a steady baseline of operations that eats the headroom you were relying on for traffic peaks. Check for a `debug.log` that nobody turned off — it is the most common single find.

Media Uploads and On-the-Fly Image Resizing

Uploads are the one genuinely throughput-shaped workload most sites have. A large image or video moves real volume, and WordPress then generates every registered thumbnail size from it, each one a read and a write. A theme registering a dozen sizes turns one upload into dozens of operations. Bulk regeneration after a theme change is the extreme version and can saturate the ceiling for as long as it runs. None of this is a problem at rest; all of it is a problem if it happens while customers are on the site.

Reduce Disk I/O Before You Upgrade, in Order of Payoff

Work down this list and stop when the faults stop. The order is deliberate: each step costs less than the one below it and, in our experience of these tickets, clears more.

Order	Change	What it removes	Effort
1	Turn on full-page caching and verify it is actually serving	Several hundred operations per cached hit	Minutes
2	Move WP-Cron to a real cron job at a quiet hour	Scheduled work landing during peak traffic	Minutes
3	Cap post revisions and clear expired transients	Unbounded table growth and repeated writes	Minutes
4	Reschedule backups and security scans off-peak	A second heavy workload competing with visitors	Minutes
5	Disable debug logging and audit autoloaded options	A constant write baseline on every request	An hour
6	Reduce registered image sizes and stop on-the-fly resizing	Dozens of write operations per upload	An hour
7	Add missing database indexes for slow queries	Repeated full scans reading rows you do not need	Developer time

When the Honest Answer Is a Bigger Disk I/O Ceiling

Sometimes the writes are the business. If you have worked down that list and the Snapshot tab still shows real orders, real logged-in sessions and real uploads at the moment of each fault, then nothing is misconfigured and you have simply outgrown the allocation. The test we use is whether you can name what is generating the operations: if you can and it is customers, the ceiling is the problem; if you cannot, it is not.

That is the point at which a tier change is the fix rather than an upsell, and it is worth knowing that the ladder moves both ceilings together — throughput, operations, entry processes, memory and CPU all step up on the same tier. For a content or membership site the next step up on managed WordPress hosting is usually enough; a store whose checkout is the bottleneck is better served by WooCommerce-tuned hosting where the uncacheable paths are the design assumption. If the Snapshot shows sustained saturation rather than peaks, the shared model itself is the constraint and VPS hosting gives you the whole allocation instead of a slice of one; genuinely I/O-bound applications belong on a dedicated server. We walk the shared-to-VPS decision in more depth in our comparison of shared and VPS hosting for growing websites. Tune first; move when the tuning runs out.

Estimate Your Disk I/O Headroom

This is arithmetic rather than measurement, and it is here to tell you whether the question is worth pursuing at all. Put in your peak uncached request rate and it will tell you roughly where you sit against the operations ceiling on each tier.

A Practical Checklist for Diagnosing Disk I/O Throttling

• The slowness is load-dependent and there is no 508, no 503 and no fatal error in the log.
• cPanel, Logs, Resource Usage has been filtered to the minutes of the slowdown rather than read as a daily average.
• The Faults column has been read on the I/O row and the IO operations row, not the usage percentage.
• Entry process faults were checked in the same window, so you know which ceiling moved first.
• At least one fault has been opened in the Snapshot tab and the process or query behind it can be named.
• Full-page caching is on and verified as actually serving, not merely installed.
• Scheduled work — cron, backups, scanners — runs outside your peak traffic hours.
• Post revisions are capped, expired transients are cleared and no debug log is being written.
• Your plan’s published throughput and operations ceilings are known, along with how far the next tier moves them.
• If faults persist after all of the above, the customer-facing work generating them can be named.

Frequently Asked Questions About Disk I/O Limits on Shared Hosting

Why is my website slow when CPU and memory look fine in 2026?

Typically because the ceiling you are hitting does not produce an error at all. CloudLinux enforces six per-account limits, and two of them — throughput and operations per second against the disk — are enforced by slowing your processes down rather than by refusing the request. Your CPU graph stays low precisely because your processes are asleep waiting on the disk instead of running. Open cPanel, go to Logs and then Resource Usage, and read the Faults column for the window when the site was slow; that is the only reading that separates this from an application problem.

What does a disk I/O fault in cPanel actually mean?

Specifically, it means your account asked the disk for more than your plan allows during that measurement period, and the server made your processes wait. A fault is a recorded violation rather than a warning: the usage chart can sit close to the ceiling all day without a single fault, and one fault is proof that the ceiling was reached and enforced. Faults are counted separately for throughput and for operations per second, so the two rows tell you different things. A handful of faults during a backup window is normal; faults every hour during business hours are a capacity finding.

Disk I/O vs IOPS: which limit slows a WordPress site first?

In practice IOPS usually binds first on a WordPress site, because WordPress issues a very large number of very small reads rather than a few large ones. Throughput measures megabytes per second and is exhausted by big sequential transfers such as a backup archive or a video file. IOPS measures how many separate read and write operations you may perform each second, and a single uncached WordPress request performs hundreds of them across PHP files, the object cache and the database. A site can therefore be nowhere near its megabytes-per-second ceiling and still be throttled all afternoon.

Disk I/O limit vs entry process limit: how do the symptoms differ?

By contrast with a disk I/O limit, an entry process limit fails loudly. When you run out of entry processes the server refuses the request and returns a 508 or a 503, so you get an error page, a log line and something to search for. When you run out of disk throughput or operations you get no error at all — the same page loads, just slowly. The two are connected, though: a request held asleep on the disk keeps occupying its entry process, so sustained throttling can eventually exhaust the concurrency ceiling and produce a 508 whose real cause is the disk.

What is the disk I/O limit on AHosting shared hosting plans in 2026?

Notably, AHosting publishes the figure rather than describing it in adjectives. The Bronze plan allows 10 MB/s and 1,024 IOPS, Silver allows 20 MB/s and 2,048 IOPS, and Gold allows 30 MB/s and 3,072 IOPS, alongside 30, 40 and 50 entry processes respectively. Those numbers are on the plan pages because you cannot size a plan against a ceiling you are not told. Check them against the Faults column in your own Resource Usage screen before you decide whether the answer is a tuning job or a tier.

My WooCommerce store slows down at checkout: is that a disk I/O problem?

Indeed, and the checkout page is the most likely place on a store for it to show. Cart and checkout are deliberately excluded from page caching because they are personal to the shopper, so every one of those requests runs PHP, reads the database and writes session and order data. Under concurrent load that is a burst of small write operations against the same ceiling. Check the Faults column for the exact minutes of the slowdown; if the operations row shows faults and the entry process row does not, the disk is the constraint rather than the worker count.

Should I upgrade my plan or reduce writes if faults appear every day?

Ultimately that depends on whether the writes are useful. Reduce first when the load is waste — unbounded post revisions, expired transients that never clear, a backup plugin archiving the whole account every night inside your own limit, a security scanner walking every file at midday. Upgrade when the writes are the business: real orders, real logged-in sessions, real uploads. The honest test is whether you can name what is generating the operations. If you can and it is customers, the ceiling is the problem; if you cannot, the ceiling is not.

How does LiteSpeed Cache on AHosting change how much disk I/O WordPress uses?

Fortunately, a cached page skips almost all of the work that generates operations. Serving an uncached page means executing PHP, reading the plugin and theme files, and running the queries behind the page; serving the same page from the LiteSpeed cache means reading one prepared file. On AHosting a cached page also consumes zero entry processes, so caching relieves both ceilings at once. That is why caching is the first fix rather than a later one, and why a site whose traffic is mostly logged-in or mostly checkout gets much less relief from it.

How do I check disk I/O usage in cPanel Resource Usage in 2026?

First and foremost, open cPanel, go to Logs and then Resource Usage. The Current Usage table lists a row for input and output and a separate row for IO operations, each showing your usage, your limit and a fault count. Filter the charts to the day, hour or minute of the slowdown rather than reading a 24-hour average, because an average hides a ten-minute stall completely. If any faults are recorded, open the Snapshot tab for that moment: it captures the process list and the database and HTTP queries that were running when the limit was hit.

Does an AHosting plan upgrade raise the IOPS ceiling as well as disk I/O?

Indeed it does, and the two rise together on every tier. Moving from Bronze to Silver takes throughput from 10 MB/s to 20 MB/s and operations from 1,024 to 2,048 per second; moving to Gold takes them to 30 MB/s and 3,072. Entry processes, memory and CPU rise on the same steps, so a tier change lifts the concurrency ceiling and the disk ceiling together rather than trading one against the other. If the operations row is the one showing faults, that is the number to check on the tier you are considering.