Author: Matt Chrust

Matt Chrust

Director of Business Development, AHosting Matt has led business development at AHosting since the company’s founding in 2002. He writes about WordPress hosting infrastructure, server performance, and the evolving requirements of WordPress sites at scale.

Autoloaded Options Could Affect Performance: How to Read the Site Health Warning and Clear It on Shared Hosting

What "Autoloaded Options Could Affect Performance" Actually Measures
Why the Autoloaded Options Warning Appeared on a Site Nobody Touched
What Autoloaded Options Cost on Shared Hosting
How to Measure Your Autoloaded Options in Three Places
How to Reduce Autoloaded Options Safely, in Order of Payoff
Estimate What Your Autoloaded Options Hold at Full Concurrency
When Reducing Autoloaded Options Is Not the Fix
A Practical Checklist for Clearing the Autoloaded Options Warning
Frequently Asked Questions About Autoloaded Options on Shared Hosting

TL;DR

The warning that autoloaded options could affect performance means WordPress now loads more than 800 KB of settings before it routes every uncached request. Cached pages never pay it; your admin, your checkout and every logged-in view pay it in full. Export the options table, clear expired transients, delete leftovers from removed plugins, then switch autoload off per large row — never wholesale.

The message is short, it is marked critical, and it appeared on a site you did not change: autoloaded options could affect performance. Site Health prints a row count and a size beside it, neither of which means much on its own, and the advice you find next tends to be a plugin recommendation. This guide explains what the check measures, why it started firing on sites that had been fine for years, and what the cost actually is on a shared hosting account, where most of your visitors never pay it and you pay it on every click. Then it walks the cleanup in the order that clears the most with the least risk.

Listen: why the warning appeared on sites nobody changed, why visitors never pay the cost while the admin always does, and the order to clean it up in. By Matt Chrust, Director of Business Development, AHosting.

What “Autoloaded Options Could Affect Performance” Actually Measures

The warning measures one number: the combined size of every option WordPress loads before it knows which page it is serving. Settings live in the wp_options table, and each row carries an autoload flag. Rows flagged on are fetched together in a single query on every request that reaches PHP, unserialized into memory, and held for the life of that request so that core, the theme and every plugin can read their settings without a query each. That single load is what the check weighs.

Specifically, the Site Health test for autoloaded options sums the byte length of those rows and raises a critical issue at 800,000 bytes. The message is worth reading precisely, because it carries two numbers: “Your site has 1,068 autoloaded options (size: 1 MB) in the options table, which could cause your site to be slow.” The count tells you how many rows are loaded before routing; the size tells you how much data they carry. Size is the one that hurts, since a single 600 KB row costs more to fetch and unserialize than three hundred rows of a few bytes.

The warning is a measurement, not a diagnosis. It cannot tell you whether the set is made of settings a live plugin reads on every page or the debris of plugins you removed in 2021, and it says nothing about whether any visitor ever feels the cost. Both of those depend on where the request came from, which is the part this guide is about.

Why the Autoloaded Options Warning Appeared on a Site Nobody Touched

Three things changed in WordPress 6.6, released in July 2024, and together they explain why a site that had been quiet for years suddenly reported a critical issue. None of them made your options larger. One of them made you look.

The 800 KB Threshold Is New, but the Data Is Not

The check itself is what arrived in 6.6. Before that release, nothing in WordPress measured the autoloaded set, so a site could carry 4 MB of leftover settings for years and never hear about it. Upgrading did not create the problem; it installed the instrument. That is why the warning reads as though something broke, when what actually happened is that a total which had been growing since the site was built was printed for the first time.

Large Options Stop Being Autoloaded at 150 KB, but Only Going Forward

The same release changed how new options are stored. The Options API dev note for 6.6 describes a size threshold, defaulting to 150,000 bytes, above which an option written without an explicit autoload instruction is no longer loaded on every request. It also replaced the old yes-or-no flag with five values — on, off, auto, auto-on and auto-off — and the loader now treats yes, on, auto-on and auto as loaded. Two consequences follow. A plugin that explicitly asks for autoload still gets it at any size, and rows written before 6.6 keep whatever flag they had. So any row over 150 KB that is still in your set is either older than the change or deliberately forced on, and either way it is the first thing to look at.

Transients Without an Expiry Are Autoloaded Options Too

A transient is a cached value stored as an ordinary option row, and its expiry decides its autoload flag: set with no expiry it is written as autoloaded, set with one it is not. Plugins use the no-expiry form for things they expect to refresh themselves, and when the plugin goes, the rows stay. The scheduled-events list is stored the same way, as one autoloaded option that grows with every recurring task a plugin registers, which is one reason a site with a busy cron schedule tends to carry a larger set than its plugin count suggests.

What Autoloaded Options Cost on Shared Hosting

The generic answer is “memory and speed,” and it is half right in a way that sends people to the wrong fix. On a CloudLinux shared account the cost has a specific shape, because the account has a fixed number of concurrent PHP requests and a fixed pool of memory they all share, and because most requests never reach PHP at all.

Cached Pages Pay Nothing, Uncached Requests Pay Every Time

A page LiteSpeed serves from LSCache never starts PHP, so no options are loaded, nothing is unserialized, and on our platform that request consumes zero entry processes. The autoloaded set costs exactly nothing on that path, however large it is. Every request that reaches PHP pays the full price: the admin, every logged-in page view, a cart, a checkout, every AJAX call, search, scheduled tasks, and the first hit on any page before the cache holds it. Our guide to splitting TTFB into cached and uncached shows how to measure that difference on your own site, and it is the first thing to do before blaming the database.

An object cache does not change which path pays. WordPress checks the persistent cache for the whole autoloaded set before it queries the database, so a cache such as Redis or Memcached removes the query, but the set is still unserialized into PHP memory on every request that reaches PHP. That makes a bloated set cheaper, not free.

Every Concurrent Request Holds Its Own Copy: the AHosting Autoload Headroom Ladder

Each request that reaches PHP holds its own copy of the set for as long as it runs, and the account’s physical memory ceiling is shared by all of them. Our plan pages publish both halves of that arithmetic, the entry-process ceiling and the account memory, so the cost can be stated rather than described:

Plan	Entry processes	Account memory	Per-request budget at full concurrency	Set held at 800 KB, all requests at once	Set held at 3 MB, all requests at once
Bronze	30	2 GB	68 MB	24 MB (1.2%)	90 MB (4.4%)
Silver	40	3 GB	77 MB	32 MB (1.0%)	120 MB (3.9%)
Gold	50	4 GB	82 MB	40 MB (1.0%)	150 MB (3.7%)

The AHosting Autoload Headroom Ladder — entry processes and account memory from the published shared and WordPress plan pages; the remaining columns are arithmetic on those two figures. Occupancy is a floor: unserialized arrays are larger than their bytes.

Two things are visible in that table that the generic warning hides. The first is that memory is rarely the ceiling: even a set well past the line occupies a few percent of the account at full concurrency. The second is the per-request budget. When every entry process is busy, each request on Bronze has about 68 MB of the account to itself, and the set is subtracted from that before a single plugin has run. A request that needs more than its share reduces how many can run at once, so memory can become the first limit before the entry-process ceiling is ever reached. If you are already watching that ceiling, our write-up of the 508 resource limit error explains what it looks like from the other side.

Why the Admin Feels the Autoloaded Options Cost Before Visitors Do

A logged-in admin session is uncacheable, so every click in the dashboard runs the full boot, including the load. Visitors are served pages the cache built earlier and never see it. This is why a bloated set produces the specific complaint of an admin that feels slow while the public site tests fast, and why the same set on a store shows up at the cart and the checkout, which cannot be cached either. Stores compound it, because a busy admin also generates a steady stream of Heartbeat and admin-ajax requests, each of which is a full uncached boot. That is the reason our WooCommerce plans are sized on the uncached path rather than on catalog traffic, and it is the reason this cleanup pays off more on a store than on a blog with the same numbers.

How to Measure Your Autoloaded Options in Three Places

Three readings settle what you have, and each answers a different question. Site Health gives you the total, the database gives you the rows, and the command line gives you a number you can put in a monitoring script.

Site Health: the Total and the Count

Go to Tools, then Site Health, and read the Status tab. The autoloaded options item sits under Critical issues when the set is over the line and under Passed tests when it is not, and in both cases it prints the row count and the size. Write both down before you change anything, because the difference after each step is how you know which step mattered.

phpMyAdmin: the Query That Matches What WordPress Loads

Open phpMyAdmin from the Databases section of cPanel, as cPanel’s phpMyAdmin documentation describes, select the site’s database, and open the SQL tab. Most guides still filter on autoload = 'yes', which under-counts on any site running 6.6 or later, because rows written since then carry the new values. The query below matches the same four values the loader itself uses:

SELECT COUNT(*), ROUND(SUM(LENGTH(option_value))/1024) AS kb FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto');

Then list the rows by size, using the same filter with ORDER BY LENGTH(option_value) DESC LIMIT 25 in place of the sum. The names usually identify the owner: a prefix matching a plugin you still run, a prefix matching one you removed, or _transient_ and _site_transient_ for cached values. If your table prefix is not wp_, substitute it in both queries. Our knowledge base article on cleaning up the WordPress database covers the rest of the table, including revisions and spam.

WP-CLI, If Your Shell Has It

Where WP-CLI is available, one command prints the total in bytes: wp option list --autoload=on --format=total_bytes, as the wp option list reference documents, and adding --fields=option_name,size_bytes lists the rows with their sizes. Put the first form in a weekly cron job and you have a trend line, which is worth more than any single reading: a set that grows 50 KB a week has an active writer, and finding it matters more than the cleanup.

How to Reduce Autoloaded Options Safely, in Order of Payoff

Work down this list and re-read Site Health after each row. The order is deliberate: every step is cheaper and safer than the one below it, and on the accounts we see the first three clear most cases. Nothing here needs a plugin, though one is named where it genuinely helps.

Order	Change	What it does to the set	Reversible?
1	Export the options table as SQL from phpMyAdmin before touching anything	Nothing yet; this is the undo button for every row below	It is the undo
2	Clear expired transients (WooCommerce: Status, then Tools, then Clear expired transients)	Removes cached values whose time has passed	They regenerate
3	Delete rows whose prefix belongs to a plugin you have uninstalled	Removes the debris that is usually most of the total	From the export
4	Set autoload off, per row, on large rows a live plugin does not need on every request	Keeps the data, stops loading it	Set it on again
5	Measure which loaded options are actually used, then switch the unused ones off	Trims what the prefix method cannot classify	Set it on again
6	Find the plugin writing a row that keeps growing, and fix or replace it	Stops the set coming back	Depends on the plugin

Autoloaded options reduction in order of payoff — cheapest and safest changes first.

Row 1: Export Before Anything Else

Row 1 is not ceremony. phpMyAdmin’s export documentation puts it plainly: an SQL export can be used to restore your database, which is exactly what you want available before the first delete. Export the one table, not the whole database, and keep the file until the site has run a week.

Row 4: Switch Autoloaded Options Off per Row, Never Wholesale

Row 4 is where the real savings usually are, and it is also where people go wrong by doing it wholesale. Switching every row off makes things worse twice over: hundreds of small options that were read from one load now cost a query each, and the loader has a fallback that loads every option in the table when the autoload query returns nothing. Turn rows off one at a time, with wp option set-autoload option_name off or an UPDATE on that single option_name, starting with the largest.

Row 5: Measure Which Autoloaded Options Are Actually Read

Row 5 answers the question the prefix method cannot: whether a row from a plugin you still run is actually read on your pages. Joost de Valk built AAA Option Optimizer for exactly this, and his account of why option clutter matters is the clearest short explanation of the problem: those options are “still loaded into the memory on every pageview.” The plugin records which autoloaded options were used during real page loads over a few days, then lets you switch off or delete the ones that never were.

Estimate What Your Autoloaded Options Hold at Full Concurrency

Put in the size Site Health reported and pick your plan. If you also know the peak memory a request uses on your site, which Query Monitor shows in its overview, add that and the tool tells you whether memory or the entry-process ceiling is the limit you would reach first at peak.

Autoload Headroom Check

Take the size from the Site Health message, or from the query in the section above, and pick your plan. It tells you how far past the 800 KB line you are, what the set occupies across every concurrent request at once, and how much of the per-request budget it takes before a single plugin has run.

Your plan

Autoloaded options size in KB

Peak memory per request in MB (optional)

—

The occupancy figure is a floor: an unserialized PHP array is larger than the bytes it came from, and every request also carries its own object-cache copy of the set. The per-request budget is the account’s memory divided by its entry-process ceiling, which is what each request has when all of them are running at once.

When Reducing Autoloaded Options Is Not the Fix

Sometimes the set is already lean and the admin is still slow, and sometimes the set is large because a plugin you depend on genuinely needs it that way. Both are real, and both call for something other than another pass through the options table.

If Site Health passes and the dashboard still drags, the database is not your problem. Compare the same URL cached and uncached first, then look at the other account ceilings, because a slow admin with a small option set usually turns out to be a CPU, memory or throughput limit being reached, and disk I/O throttling in particular produces exactly this symptom without ever printing an error. Raising the PHP memory limit is not the answer either; our memory limit guide explains why a per-script limit cannot create memory the account does not have.

If the set is large for a reason, the honest fix is headroom rather than deletion. A plugin that keeps a big autoloaded structure because it reads it on every request is doing its job, and the cost it imposes is paid by concurrency. The cleanup above is the part you own; the ceilings it runs against are the part we publish, and the tier that fits is the one whose per-request budget your own reading lands inside. For a content site that is usually the next step on managed WordPress hosting, where the whole ladder moves together; for a general PHP application the same ceilings are listed on our shared web hosting plans; and where a single account carries many sites, each with its own set, VPS hosting gives every site the whole pool rather than a share of one.

A Practical Checklist for Clearing the Autoloaded Options Warning

Site Health has been read and both numbers, the row count and the size, were written down before any change.
One URL has been timed cached and uncached, so the cost is known to be on the uncached path rather than assumed.
An SQL export of the options table exists, taken from phpMyAdmin, and the file is somewhere you will find it.
Your size query used the four loader values, not autoload = 'yes' alone, so it matches what WordPress loads on a 6.6-or-later site.
Each of the 25 largest rows has an owner named: a live plugin, a removed plugin, or a transient.
Expired transients have been cleared, from the WooCommerce tools where the store runs or from a cleanup tool where it does not.
Rows belonging to uninstalled plugins have been deleted, and rows whose owner cannot be named have been switched off rather than deleted.
Any row over 150 KB that is still autoloaded has been switched off per row, never with a table-wide update.
Site Health has been re-read after each step, so the step that mattered is known.
If the set is under the line and the admin is still slow, the diagnosis has moved on to the account ceilings rather than back to the database.

Frequently Asked Questions About Autoloaded Options on Shared Hosting

How do I clean up autoloaded options in WordPress in 2026 without breaking the site?

First and foremost, export the options table before you touch it, then work in a fixed order: clear expired transients, delete the rows left behind by plugins you have already uninstalled, and only then turn autoload off for large rows that belong to plugins you still use. Every step except the last is reversible from the export, and the last one is reversible by turning autoload back on. The rule that keeps you safe is simple: never delete an option whose owner you cannot name. If a row's prefix does not match a plugin you recognize, set its autoload off rather than deleting it, and check what the site does over the following day.

What does the Site Health warning "Autoloaded options could affect performance" actually measure?

Specifically, it adds up the byte length of every row in the options table that WordPress loads on every request, and raises a critical issue when that total reaches 800,000 bytes. The check arrived in WordPress 6.6 and prints both the row count and the size, so a message reading 1,068 autoloaded options at 1 MB is telling you two things: how many rows are loaded before the page is routed, and how much data they carry. The number of rows matters less than the size, because one 600 KB row costs more to fetch and unserialize than three hundred rows of a few bytes each.

Autoloaded options vs transients: which one is filling the wp_options table?

In practice the two overlap, which is what makes the question confusing. A transient is stored as an ordinary option row, and a transient set with no expiry is written with autoload switched on, so it becomes part of the autoloaded set. A transient with an expiry is written with autoload off, so it fills the table without being loaded on every request. That distinction decides what each one costs you: expired transients with an expiry waste disk and slow the table down, while transients without one are loaded into memory on every uncached request until something deletes them.

Page cache vs object cache: which one stops autoloaded options from costing anything on AHosting?

Notably, only the page cache does. A page that LiteSpeed serves from LSCache never starts PHP, so no options are loaded and nothing is unserialized; on AHosting that request also consumes zero entry processes. A persistent object cache is different. It removes the database query, because WordPress checks the cache for the whole autoloaded set before it queries, but the set is still unserialized into PHP memory on every request that reaches PHP. So an object cache makes a bloated set cheaper per request, while a page cache makes it free on the requests it serves and leaves the admin, the checkout and every logged-in view paying the full price.

Why is wp-admin slow while visitors say the site is fast on AHosting shared hosting in 2026?

Typically because the two audiences are served by different paths. Visitors get pages LSCache built earlier, which skip PHP entirely, while a logged-in admin session is uncacheable and runs the full WordPress boot on every click, including loading and unserializing every autoloaded option. A large autoloaded set is therefore invisible to visitors and paid in full by the person who would notice it least kindly. The same split explains why a WooCommerce cart or checkout, which cannot be cached either, feels slower than the product pages around it.

Why are some autoloaded options larger than 150 KB still loading after the WordPress 6.6 change?

In fact the 6.6 rule only governs options written without an explicit autoload instruction. When a plugin saves a value that way and it exceeds roughly 150 KB, WordPress now records it as not autoloaded, but a plugin that explicitly asks for autoload still gets it at any size, and rows written before 6.6 keep whatever flag they already had. So a large row that is still loading on every request is one of two things: a legacy row from before the change, or a row a plugin deliberately marked to load every time. Both are fixed the same way, by setting that row's autoload off if nothing needs it on every request.

How many autoloaded options can a WordPress site hold on an AHosting Bronze plan before memory becomes the problem?

Interestingly, memory is almost never the ceiling the warning is about. On a Bronze plan the account holds 2 GB and allows 30 concurrent PHP requests, so even at the 800 KB threshold the autoloaded set occupies about 24 MB across all of them at once, and a 3 MB set occupies about 90 MB, a few percent of the account. What the warning is really about is the work each uncached request does before it can route the URL, and how much longer that request holds an entry process while it does it. The figure to watch is the per-request budget: at full concurrency each request on Bronze has about 68 MB of the account's memory, and a bloated set eats into that before any plugin runs.

Is 800 KB of autoloaded options still the right threshold in 2026 for a WooCommerce store?

Ultimately the 800 KB figure is WordPress's own line, unchanged since it was introduced in version 6.6, and it is a sensible warning level rather than a hard limit. Our support team's rule of thumb from the accounts we see is that a set under 1 MB is fine and one over 3 MB is worth an hour of your time. A store deserves more attention than a brochure site, not because the threshold changes but because more of its requests are uncached: cart, checkout, account pages and every AJAX call pay the full cost. A store sitting at 2 MB with a busy checkout is paying more for the same set than a blog sitting at 2 MB whose visitors are all served from cache.

Will setting all autoloaded options to autoload off make WordPress faster on shared hosting?

By contrast with the cleanup this guide recommends, switching every row off makes things worse in two ways. WordPress loads the set in one query precisely so that the hundreds of options core and your plugins read on every request do not each become their own query, so a site with nothing autoloaded runs hundreds of small queries where it used to run one. Worse, the loader has a fallback: if the autoload query returns no rows at all, it loads every option in the table instead, which is the largest possible set. Turn autoload off per row, for rows that are large and not needed on every request, and leave the small ones alone.

Should I raise the PHP memory limit to fix the autoloaded options warning in 2026?

That said, raising the limit changes nothing about the warning and very little about the cost. The check measures the size of the set, not the memory PHP is allowed, and the work of fetching and unserializing the rows is the same at any memory limit. Our plans allow a PHP memory limit of up to 512 MB, and the account also has a separate physical memory ceiling that every concurrent request shares, so a higher per-script limit does not create memory that is not there. Reduce the set instead; the limit only decides how large a single request may grow before it fails.

September 10, 2026

Your Hosting Says 100% Full With 8 GB Free: How to Fix a WordPress Inode Limit

Why an Inode Limit Reports "Full" While Your Disk Is Half Empty
How to Check Your Inode Limit and Usage in cPanel
The AHosting Inode Ladder and the 42 KB Crossover
What Actually Eats Inodes on a WordPress Account
Find the Real Consumer: A Directory-Level Inode Census
Reduce Inode Usage Safely, in Order of Payoff
Estimate Which Ceiling You Will Hit First
When the Honest Answer Is a Higher Inode Ceiling
A Practical Checklist for Clearing an Inode Limit
Frequently Asked Questions About Inode Limits on Shared Hosting

TL;DR

An inode limit counts files, not bytes, so an account can report itself full with most of its disk unused. Open cPanel and read the File Usage row in the Statistics panel against the Disk Usage row above it. If the file count is near its ceiling while storage is not, adding gigabytes fixes nothing — find the directory holding the files instead, and start with mail, cache and old backups.

Nothing about this failure looks like a capacity problem, which is exactly why it costs people an afternoon. The media library refuses an upload. A plugin update dies halfway through. Last night’s backup says it finished and produced no file. Then you open cPanel, see 3 GB used of 10 GB, and conclude the host is broken. It is not: you have hit an inode limit, a second ceiling that counts how many files you store rather than how large they are. This guide shows you how to confirm it in two minutes, how to find the directory actually responsible instead of guessing, and how to tell a cleanup job from a tier you have genuinely outgrown.

Listen: why a hosting account can refuse every write with gigabytes of disk unused, and the four directories that almost always turn out to be holding the files. By Matt Chrust, Director of Business Development, AHosting.

Why an Inode Limit Reports “Full” While Your Disk Is Half Empty

Your account is capped twice, and the two caps measure different things. One counts bytes and is the number every hosting plan advertises. The other counts entries in the file system — one per file, one per directory — and most people never see it until it stops them. In POSIX terms that entry is the file serial number, described in the standard as a per-file-system unique identifier for a file; on Linux it is universally called an inode, and cPanel labels the running total File Usage.

The consequence of counting entries rather than bytes is the whole of this problem. Size is irrelevant to the count: one 2 GB archive costs a single entry, while 20,000 cache fragments of four kilobytes each cost 20,000. An account can therefore be 96 percent of the way through its file allowance while showing a third of its disk used, and no graph anyone normally looks at will hint at it.

What breaks when the ceiling is reached is every write, all at once and permanently until something is deleted. Uploads fail. Updates fail partway and leave a half-installed plugin. Incoming mail is rejected at the server. Worst of all, scheduled backups stop producing files while still reporting success, so the one thing that would let you recover quietly stops existing. Reading is unaffected, which is why visitors notice nothing and you notice everything.

How to Check Your Inode Limit and Usage in cPanel

Two numbers settle this, and both are already on the screen you land on. Log in to cPanel and look at the Statistics panel down the right-hand side. Find the row labeled File Usage: it prints your current count and your ceiling, separated by a slash, in the form 249,120 / 250,000. Directly above it sits Disk Usage in gigabytes.

Read them as a pair, never one at a time. That pairing is the diagnostic, because it tells you which ceiling is close and therefore which problem you actually have:

File Usage near its ceiling, Disk Usage nowhere near — this article. More storage would change nothing.
Disk Usage near its ceiling, File Usage comfortable — an ordinary storage problem. Find the large files.
Both close — the account is simply full in every sense, and the tier is the answer rather than a cleanup.
Neither close, writes still failing — not a capacity problem at all. Check file permissions and ownership before anything else.

One caution about the reading itself: File Usage is a snapshot updated on a schedule, not a live counter, so a large deletion can take a while to show. Give it time before concluding that a cleanup achieved nothing. Our knowledge base covers the same ground from the server side in understanding inodes and running out of them.

The AHosting Inode Ladder and the 42 KB Crossover

Most hosts do not publish a file ceiling at all, which makes the number impossible to plan against. We publish it on the plan pages beside the storage figure, and reading the two together produces something more useful than either alone. Divide the storage a plan allows by the files it allows and you get the average file size at which both ceilings fill on the same day. Below that figure the count binds first; above it, storage does.

Plan	SSD storage	File ceiling	Files per GB	Crossover average file size
Bronze	10 GB	250,000	25,000	42 KB
Silver	20 GB	400,000	20,000	52 KB
Gold	50 GB	600,000	12,000	87 KB

The AHosting Inode and Storage Ladder — ceilings published on the shared and managed plan pages, and the average file size at which the two ceilings meet on each tier.

Two things fall out of that table. The first is a test you can apply to your own account in ten seconds: mail messages average a few kilobytes, cache fragments similar, and thumbnails commonly run 10 to 60 KB, so any account whose bulk is those three sits below the crossover. Photo originals, video and archives sit far above it.

The second matters when you are choosing a tier. Files per gigabyte falls as the ladder rises — 25,000, then 20,000, then 12,000 — because larger plans are shaped for accounts holding larger files. Gold carries five times the storage of Bronze but only 2.4 times the inode limit. For a media library that is right; for a mail-heavy account it means a tier buys less relief than the storage headline suggests. Every tier is listed on our shared web hosting plans.

What Actually Eats Inodes on a WordPress Account

Four things account for almost every case of an inode limit, and WordPress core is not one of them. A bare installation with a theme and a handful of plugins usually holds 10,000 to 20,000 files, a small fraction of even the entry ceiling. Everything below grows without a natural stopping point, which is the property that matters.

Media Uploads, Multiplied by Every Registered Size

One photograph is never one file. WordPress generates a derivative for each registered image size, and core alone reserves several by name — thumbnail, medium, medium_large and large — then adds further default sub-sizes on top, as the add_image_size reference sets out. Themes and page builders register more. Since version 5.3 an upload wider than 2,560 pixels also gets a scaled copy alongside the preserved original, so a single large photograph can land as eight files. Upload a thousand and the arithmetic stops being abstract.

Email, Where Every Message Is Its Own File

This is the one that catches people, because mail feels like it lives somewhere else. It does not. cPanel stores mail in Maildir format, whose founding property is that each message is stored in a separate file with a unique name. A mailbox holding 40,000 messages is holding 40,000 entries against your ceiling, and Spam and Trash folders are the usual culprits precisely because nothing empties them and nobody looks. Attachment size is beside the point here: a hundred one-line notifications cost exactly what a hundred invoices cost.

Page and Object Caches, Which Write a File Per Cached URL

Caching trades files for speed, and the trade is usually worth making. Full-page caching stores each cached page on disk, so a site with 5,000 URLs can hold thousands of cache files, and warming the cache with a crawler builds that set on purpose. LiteSpeed’s own cPanel documentation shows the per-site cache root configured under the account home directory, so on most cPanel servers those files sit inside your quota. Purging is not a fix, merely a deferral, and it costs you the performance you turned caching on for.

Backups, Staging Copies and Migration Leftovers

Duplicate trees are the quiet giant. A staging site is a second complete copy of every file you have, which is why we recommend running one on hosting built for WordPress staging rather than as a folder inside a full account. Backup plugins that keep local copies store an extracted tree per restore point. Migration debris outlives its usefulness by years, and our guide to migrating WordPress to a new host ends with the cleanup step most people skip.

Find the Real Consumer: A Directory-Level Inode Census

Guessing is the expensive part of this job. Deleting things at random can free tens of thousands of entries and still leave you at the inode limit, because the directory responsible was somewhere you never opened. A census fixes that by ranking directories by file count, and it takes about five minutes.

If you have terminal access, one command does the whole job. GNU coreutils documents du –inodes as being useful for exactly this — finding the directories that contain many files. Run du --inodes -x -d 3 ~ | sort -rn | head -30 from your home directory and read the list from the top; -x keeps it on one file system and -d 3 stops it drowning you in depth.

Without terminal access the same result comes from cPanel’s File Manager, more slowly. Start at the account root and work down, checking these five locations in this order, because they are ranked by how often each turns out to be the answer:

mail/ — every domain, and inside each one the Spam, Junk and Trash folders.
public_html/wp-content/cache/ and any sibling cache directory a plugin created.
public_html/wp-content/uploads/ — sorted by year, so you can see when it accelerated.
Old backup and staging directories anywhere in the account, including outside public_html.
.trash, tmp and .cagefs, which are easy to forget and occasionally enormous.

Write down the count before you start deleting. Without a baseline you cannot tell whether a cleanup freed 2,000 entries or 200,000, and that difference decides whether the next step is another cleanup or a tier.

Reduce Inode Usage Safely, in Order of Payoff

Work down this list and stop when File Usage drops clear of the inode limit. Order is deliberate: each row costs less than the one below it and, on the tickets we see, clears more. Every one of them is reversible except where noted.

Order	Change	What it frees	Effort
1	Empty Spam, Junk and Trash on every mailbox, then set them to auto-purge	Often 30–60 percent of the count on a mail-heavy account	Minutes
2	Delete old backup archives and any extracted restore trees held locally	Whole duplicate file trees at once	Minutes
3	Remove staging and migration leftovers you no longer need	A second complete copy of the site	Minutes
4	Purge page and object cache directories once, as a temporary measure	Thousands of small files, which will rebuild	Minutes
5	Uninstall plugins and themes you do not use, rather than deactivating them	Deactivating frees nothing; the files remain	Minutes
6	Unregister image sizes you never serve, then regenerate thumbnails	Several files per uploaded image, permanently	An hour
7	Move video and large media to object storage or a media host	Removes the growth curve rather than a snapshot	Developer time

Inode reduction in order of payoff — highest-yield and cheapest changes first.

Row 6 deserves a warning, since it is the only one that is not simply reversible: unregistering a size and regenerating thumbnails deletes derivatives that existing posts may reference. Check what your theme actually serves before you run it. Row 5 deserves a correction of a common belief — deactivating a plugin frees nothing at all, because every file stays exactly where it was.

Estimate Which Ceiling You Will Hit First

Both numbers this needs are on your cPanel home screen already. Put them in and it will tell you how far along each ceiling you are, what your average file size works out at, and which of the two will stop you first — which is the only question that decides what you should do next.

Inode Limit Headroom Check

Both figures this needs are already on your cPanel home screen: File Usage and Disk Usage, in the Statistics panel. It compares how far you are along each ceiling and names the one that will stop you first.

Your plan

Your File Usage count

Your Disk Usage in GB

—

Average file size is your storage divided by your file count, and it is the number that decides which ceiling you meet first. Deleting one large archive changes the disk figure and barely moves the file figure; emptying a spam folder does the opposite.

When the Honest Answer Is a Higher Inode Ceiling

Sometimes the files are the business. If you have worked down the list and what remains is a real media library, real customer mail and a cache serving real traffic, then nothing is misconfigured and the allowance is simply too small for what you run. The test we use is whether you can name what is holding the entries: if you can and it is work the site actually does, the ceiling is the problem; if you cannot, it is not.

That is the point where a tier change is the fix rather than an upsell, and the ladder moves every account-wide ceiling on the same step — file count, storage, entry processes, memory and disk throughput together. A content or membership site is usually served by the next step up on managed WordPress hosting. A store is a different shape: order mail, invoices and product image variants make stores unusually file-dense for their size, which is worth knowing before you size WooCommerce hosting. Where a single account is carrying many sites, the shared model itself is the constraint and VPS hosting gives you the whole file system rather than a slice of one.

Before you decide, check the other ceilings in the same sitting, because accounts that run out of files often turn out to be near something else as well. Our write-up of the 508 resource limit error covers the concurrency ceiling, and the companion piece on disk I/O throttling covers the one that never returns an error at all. Clean up first; move when the cleanup runs out.

A Practical Checklist for Clearing an Inode Limit

Writes are failing while reads work normally, and the errors blame permissions or disk space rather than an inode limit.
cPanel Statistics has been opened and File Usage read as a pair with Disk Usage, not one alone.
The file count is genuinely near its ceiling while storage is not — otherwise this is a different problem.
A baseline count was written down before anything was deleted.
Mail was checked first, per domain, including Spam, Junk and Trash on every mailbox.
Backup archives, extracted restore trees and staging copies have been located and assessed.
Cache directories were counted, and it is understood that purging them is a deferral rather than a fix.
Unused plugins and themes are uninstalled rather than merely deactivated.
Registered image sizes have been reviewed against what the theme actually serves.
If the count is still near the ceiling, the files that remain can be named and tie to work the site really does.

Frequently Asked Questions About Inode Limits on Shared Hosting

What does it mean when a hosting account hits its inode limit in 2026?

Typically it means your account has reached the maximum number of files and directories it is allowed to hold, which is counted separately from how many gigabytes those files occupy. Every file counts as exactly one entry regardless of size, so a single 2 GB archive costs one and twenty thousand tiny cache fragments cost twenty thousand. Once the ceiling is reached the account can no longer create anything: uploads fail, plugin installs fail, backups fail and incoming mail is rejected, usually with error messages that mention permissions or disk space rather than the real cause.

How do I check my inode limit and current usage in cPanel?

First and foremost, look at the Statistics panel down the right-hand side of the cPanel home screen and find the row labeled File Usage. It prints two numbers separated by a slash: the count of files and directories your account currently holds, and the ceiling your plan allows. Read that alongside the Disk Usage row directly above it, because the pair is what tells you which of the two ceilings is actually close. If File Usage reads 249,120 of 250,000 while Disk Usage sits at 3 GB of 10 GB, the file count is your constraint and adding storage would change nothing.

Inode limit vs disk space: which one runs out first on a WordPress site?

In practice the answer depends entirely on your average file size, and there is a specific number where the two ceilings meet. Divide the storage your plan allows by the file count it allows and you get the average size at which both fill on the same day. Below that figure the file count binds first; above it, storage does. WordPress accounts that carry a lot of email, a large page cache or years of thumbnail variants sit well below the crossover, which is why an inode limit surprises people who have been watching their disk graph.

Inode limit vs entry process limit: how do the two failures differ?

By contrast with an entry process limit, which throttles you only while traffic is heavy and clears itself the moment the rush passes, an inode limit is a hard stop that does not recover on its own. Running out of entry processes returns a 508 to some visitors for a few minutes; running out of files stops every write on the account until you delete something. The two also fail in different places. One is visible to your visitors and invisible in cPanel, and the other is invisible to your visitors and printed on the cPanel home screen in plain numbers.

What is the inode limit on AHosting shared hosting plans in 2026?

Notably, AHosting publishes the ceiling on the plan pages rather than describing it in adjectives. Bronze allows 250,000 files against 10 GB of SSD storage, Silver allows 400,000 against 20 GB, and Gold allows 600,000 against 50 GB. Those pairs are worth reading together, because the file allowance per gigabyte falls as the tiers rise: 25,000 per GB on Bronze, 20,000 on Silver and 12,000 on Gold. Higher tiers are calibrated for accounts holding larger files, so a mail-heavy or cache-heavy account gains proportionally less headroom from a tier change than a media-heavy one does.

Does email count toward the inode limit on a cPanel account?

Indeed it does, and on many accounts it is the single largest consumer. cPanel stores mail in the Maildir format, whose defining property is that each message is written as its own file, so a mailbox holding 40,000 messages holds 40,000 files. Spam and Trash folders are the usual offenders because nothing deletes them automatically and nobody looks at them. Attachments make the size worse but not the count; a hundred one-line notifications cost exactly as much against the ceiling as a hundred messages carrying invoices.

What happens to a WordPress site when the inode limit is reached?

Specifically, the site keeps serving pages and stops being able to write anything. Visitors usually notice nothing at first, because reading existing files is unaffected. Inside wp-admin the failures start immediately: media uploads return an error about the upload directory not being writable, plugin and core updates fail partway through, and any plugin that writes a log or a cache file fails silently. The most damaging symptom is the quiet one, which is that scheduled backups stop completing while still reporting that they ran.

How does LiteSpeed Cache on AHosting affect how many files an account stores?

Fortunately the trade is usually worth making, but it is a genuine trade and it is worth understanding before you tune anything. Full-page caching works by writing each cached page to disk as a file, so a site with 5,000 URLs can hold thousands of cache files at once, and enabling a crawler to warm the cache builds that set deliberately. On AHosting a cached page also consumes zero entry processes, so the caching layer is buying real protection against the concurrency ceiling with a modest cost against the file ceiling. Purging the cache to reclaim files is therefore a short-term fix that costs you performance.

How many files does a typical WordPress installation hold in 2026?

In fact a bare installation is small: WordPress core plus a theme and a handful of plugins usually lands somewhere between 10,000 and 20,000 files before any content exists. Growth comes almost entirely from four places, and none of them is the core software. Media uploads multiply because every registered image size becomes another file on disk, mail accumulates one file per message, page and object caches write and rewrite constantly, and old backups and staging copies duplicate whole trees. An account at 240,000 files is rarely a big website; it is usually a small website plus one of those four running unbounded.

Does upgrading an AHosting plan raise the inode limit as well as storage?

Accordingly it does, and both move on the same step rather than one at a time. Bronze to Silver takes the file ceiling from 250,000 to 400,000 while storage goes from 10 GB to 20 GB, and Gold carries 600,000 against 50 GB. Entry processes, memory, CPU and disk throughput rise on those same steps, so a tier change lifts every account-wide ceiling together. Check which one you are actually near before you decide, because an account that is at 96 percent of its file count and 30 percent of its storage is buying the file ceiling and nothing else.

September 10, 2026

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

Why a Disk I/O Limit Never Shows You an Error
How to Confirm Disk I/O Throttling in cPanel in Five Minutes
The AHosting Disk I/O and IOPS Ladder
- What 10 MB/s Actually Serves
- Why the IOPS Ceiling Usually Binds First
The Five Things That Generate WordPress Disk I/O
Reduce Disk I/O Before You Upgrade, in Order of Payoff
When the Honest Answer Is a Bigger Disk I/O Ceiling
Estimate Your Disk I/O Headroom
A Practical Checklist for Diagnosing Disk I/O Throttling
Frequently Asked Questions About Disk I/O Limits on Shared Hosting

TL;DR

A disk I/O limit never returns an error. CloudLinux puts your processes to sleep, so the page still loads and simply takes longer, which is why CPU and memory look innocent. Open cPanel, go to Logs and then Resource Usage, and read the Faults column for the minutes the site was slow. Faults on the disk rows and none on the entry process row means you are throttled, not out of workers.

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.

Listen: 9 minutes on the one shared-hosting limit that slows your site without ever failing a request. By Matt Chrust, Director of Business Development, AHosting.

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

AHosting Disk I/O and IOPS Ladder — published shared and WordPress plan allocations, verified against the live plan pages on September 9, 2026.

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

Disk I/O reduction in order of payoff — cheapest and highest-yield changes first.

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.

Disk I/O Headroom Estimator

A rough order-of-magnitude check, not a measurement. It assumes an uncached request performs about 300 small read and write operations, which is typical for WordPress with a normal plugin load. Your real figure is in the Faults column.

Your plan

Uncached requests per second at peak

Operations per uncached request

—

Cached requests are excluded on purpose: a page served from the LiteSpeed cache is one read, not three hundred. If this estimate says you are close, confirm it against the Faults column before changing anything.

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.

September 9, 2026

FFmpeg Server Requirements: How to Size a Plan From Your Own Encode Queue

FFmpeg Server Requirements Start With One Number, and It Is Not Cores
- Encode-Minutes In, Core-Hours Out
- Why Shared, VPS or Dedicated Is the Last Question
What Shared Hosting Clears Against Real FFmpeg Server Requirements
What a VPS Actually Guarantees: Cores, Threads and vCPUs
The Measured Constant: What One Minute of 1080p Costs
- What the Test Did Not Cover
- Measuring Your Own FFmpeg Server Requirements Constant
One Source Is Not One Encode: The FFmpeg Server Requirements Multiplier
- A Three-Rung Ladder Is Three Encodes
- Jobs or Threads? Both Our Numbers Are Right
The AHosting FFmpeg Encode Capacity Ladder
- How the Derived FFmpeg Server Requirements Rows Were Derived
- When Bare Metal Is the Answer
Matching Your Queue to a Tier: FFmpeg Server Requirements by Workload
A Practical Checklist: Are Your FFmpeg Server Requirements Covered?
Frequently Asked Questions About FFmpeg Server Requirements

TL;DR

FFmpeg server requirements come from one number: finished encode-minutes per day. Measure a single job, multiply by your rendition ladder, then read off the tier that clears it. The plan name is the last decision, not the first.

Most FFmpeg hosting advice ends at a recommendation: start with four to eight cores and see how it goes. That is not a specification, it is a guess with a number attached, and it fails in the two directions that cost money. Real FFmpeg server requirements are arithmetic, and the inputs are things you already know about your own queue. This post supplies the arithmetic, the measured constants it runs on, and the two boundaries the usual recommendation hides. It is the third in a series: post one found your CPU cap, post two set the per-job thread ceiling, and this one sizes the machine. If you are still deciding whether server-side media processing is the right shape for your project at all, the buyer-side guide to FFmpeg hosting covers that ground first.

Listen: 8 minutes on why cores is the wrong unit for sizing an encoding server, and the arithmetic that replaces it. By Matt Chrust, Director of Business Development, AHosting.

FFmpeg Server Requirements Start With One Number, and It Is Not Cores

FFmpeg server requirements reduce to finished encode-minutes per day. Everything else — cores, threads, tier names, price — is downstream of it. Count what your pipeline has to produce in 24 hours, and the hardware question answers itself.

Encode-Minutes In, Core-Hours Out

Encoding is one of the few web workloads with an honest unit. A visitor is unpredictable; an encode is not. Given the same source, the same codec and the same preset, a machine finishes a fixed number of output minutes per hour, and that rate barely moves. Therefore capacity planning here is closer to a factory line than to traffic estimation: throughput in, throughput out, and a queue that either drains or grows.

The unit that matters is output, not input. A single 10-minute upload that becomes three delivery renditions is 30 encode-minutes of work, not 10. Consequently the first thing to establish is your daily output figure, and the multiplier that produces it is covered further down.

Why Shared, VPS or Dedicated Is the Last Question

Tier names describe how a machine is sold, not what it finishes. Two plans with the same core count can differ in whether you are permitted to hold those cores for four hours, which is the variable that actually decides whether an encode completes. In practice the sequence runs the other way round from how it is usually presented: work out the daily figure, check which tiers are allowed to sustain that kind of load at all, and only then compare prices among the ones that clear it.

What Shared Hosting Clears Against Real FFmpeg Server Requirements

Shared hosting runs FFmpeg perfectly well for the cheap half of a media pipeline and cannot run the expensive half at all. That boundary is set by policy and by process limits rather than by raw speed, which is why adding cores to a shared plan would not move it.

Three Ceilings, and Only One of Them Is CPU

CloudLinux expresses a shared account’s CPU allowance as a percentage of one core — the documentation states that a SPEED limit of 100% means one core, so 400% means four. Notably, hitting that ceiling does not kill anything: the account simply runs slower. The two limits that actually stop an encode are different. Entry processes cap how many concurrent connections, SSH sessions and cron jobs an account may hold at once, and the execution-time limit stops a long-running job part-way.

That last one produces the symptom people misdiagnose most often. Furthermore, a truncated output file with no error message from FFmpeg reads exactly like a bad command, because FFmpeg did not fail — it was terminated. Our knowledge base article on what you can and cannot do with FFmpeg on shared hosting walks through the symptom set in detail. Worth stating plainly: a temporary entry-process increase is not a thing that exists. It is a plan change.

The Work That Does Fit on a Shared Plan

Anything that does not decode and re-encode a whole video is usually fine. Probing a file with ffprobe returns in milliseconds. Pulling a thumbnail reads a small part of the file. Stream copies — trimming, joining, remuxing — move data rather than processing it, so a two-hour source is handled in seconds. Short audio conversion is comparatively light. In fact a well-designed pipeline often keeps all of that on a standard hosting plan and sends only the encoding elsewhere.

Bronze to Gold, Translated Into Cores

AHosting’s four shared tiers carry LVE SPEED allocations of 100, 200, 300 and 400 — one through four cores — with entry-process allowances of 20, 30, 40 and 50. Those figures are read from the server configuration rather than from a plan page, and no shared plan page publishes them. Ultimately they are beside the point for this decision: the ceiling that stops sustained encoding is the execution-time limit, and it applies at every one of those tiers. If you want to see where your own account’s cap sits before deciding anything, post one in this series shows you how to find your CPU cap on shared hosting with two commands.

What a VPS Actually Guarantees: Cores, Threads and vCPUs

A VPS removes the policy ceiling and replaces it with a scheduling guarantee. That is a real change, and it is worth understanding precisely what is being guaranteed, because the words on plan pages across this industry are not consistent.

A vCPU Is a Scheduled Process, Not a Piece of Silicon

Under KVM, the project’s own documentation is blunt about this: once running, a virtual machine is just a regular process on the host, managed with ordinary tools. A guaranteed vCPU is therefore a promise about how the host scheduler treats your machine, not a physical core welded to your name. In practice that promise is what matters, and it is verifiable: AHosting’s published encode test recorded CPU steal time at zero throughout on both plans, which is the measurement that shows nothing was taking the cores back.

Six Cores or Twelve? Encoding Cares Which

Bare-metal listings across this industry mix cores and threads freely, and for encoding the difference is not cosmetic. Intel’s specification for the Xeon E-2136 gives six cores and twelve threads, while the Xeon Silver 4114 is ten cores and twenty threads per socket. A dual-4114 machine is therefore a 20-core, 40-thread box. Additionally, a second hardware thread on a busy encoder adds far less than a second core does, so a listing that prints only the larger number is describing something you will not get. AHosting’s dedicated listings print both, which is the format to insist on wherever you buy.

FFStart and FFPower Are KVM-4 and KVM-8 With FFmpeg Pre-Built

Worth knowing before you compare line items: the two FFmpeg plans are the same machines as the four- and eight-core tiers of the general VPS range, at the same prices, shipped with FFmpeg and FFprobe already compiled and on your PATH. FFStart is 4 vCPU, 8 GB and 75 GB of SSD; FFPower is 8 vCPU, 16 GB and 100 GB. Above them the KVM line continues to 16 vCPU and 32 GB. Specifically what the FFmpeg plans add is the build, not the hardware, so the sizing arithmetic below applies identically across both ranges.

The Measured Constant: What One Minute of 1080p Costs

Every FFmpeg server requirements calculation in this post rests on one measured constant, and it is published rather than estimated. AHosting Technical Operations ran the same source file and the same command on both FFmpeg plans, varying only the core count.

Job	FFStart — 4 vCPU	FFPower — 8 vCPU
Down to 720p, H.264	51.5 s — 1.16x real time	27.6 s — 2.18x real time
Stay at 1080p, H.264	88.8 s — 0.67x real time	47.5 s — 1.26x real time
1080p, HEVC (x265)	110.5 s — 0.54x real time	67.7 s — 0.88x real time
Decoding the source alone	17.0 s	10.7 s

Wall-clock time to process 60 seconds of 1920×1080 H.264 source at roughly 25 Mbps, preset medium. Mean of three runs, run-to-run variation under 2%. Published on the AHosting FFmpeg hosting page.

What the Test Did Not Cover

Three limits are worth stating before the numbers get multiplied. Firstly, the test covers four and eight vCPUs only, so every other figure in this post is arithmetic from those two rows and says so. Secondly, source complexity moves results by roughly 30% between a detailed live-action shot and a flat animated one, which is a wider band than most tier differences. Thirdly, the preset matters as much as the plan: the same job dropped from 50.3 s to 29.4 s on four cores purely by moving from preset medium to preset veryfast, and for delivery renditions that trade is usually worth taking.

Measuring Your Own FFmpeg Server Requirements Constant

Your files are not our files, so the honest version of this exercise replaces our constant with yours. Take a representative source, run your real command on your current box, and record wall-clock seconds against source seconds. That ratio is your throughput multiplier, and it slots into every calculation below in place of ours. Post one in this series covers the measurement itself, including how to tell a throttled result from a genuine one.

One Source Is Not One Encode: The FFmpeg Server Requirements Multiplier

The single most common error in estimating FFmpeg server requirements is counting uploads instead of outputs. A rendition ladder multiplies your daily figure by the number of rungs, and it does so before any hardware decision is made.

A Three-Rung Ladder Is Three Encodes

Adaptive streaming works by offering the same content at several bit rates. RFC 8216 defines the master playlist as one that references media playlists, each of which specifies media encoded at a particular bit rate, in a particular format, and at a particular resolution. Accordingly a 1080p, 720p and 480p ladder is three separate encodes of every source you accept. For example, 100 source minutes a day is 100 encode-minutes with a single output and 300 with three, and the hardware requirement triples with it.

Jobs or Threads? Both Our Numbers Are Right

Two AHosting measurements look, at first glance, as though they disagree. Our published plan test found that four simultaneous encodes on four cores returned only 1.08x the throughput of running them one after another. Post two in this series argues that past a codec’s useful thread ceiling the win comes from more jobs rather than more threads. In fact both hold, and the variable is core count: on four cores a single 1080p x264 job already occupies everything available, so fanning out buys nothing, while the parallel win appears only once a machine has more cores than one job can usefully consume. That is exactly the 16-core and bare-metal case, and it is why the thread ceiling governs the top of the ladder and not the bottom. When you do reach the point of running a queue in parallel, the knowledge base covers how to run FFmpeg jobs in parallel without overloading the box.

The AHosting FFmpeg Encode Capacity Ladder

Below is every AHosting tier on one scale, which is where FFmpeg server requirements stop being a category question and become a lookup. Two rows are measured on plans we sell; the rest are arithmetic from them, and every row says which it is. A day is 1,440 minutes, so a throughput multiplier above 1.0x means the machine finishes faster than real time.

Tier	Guaranteed cores	Sustained encoding?	1080p H.264 throughput	Finished 1080p minutes / 24 h	Basis
Bronze (shared)	1 (SPEED 100)	No — execution-time limit	—	—	Policy
Silver (shared)	2 (SPEED 200)	No	—	—	Policy
WooStart (shared)	3 (SPEED 300)	No	—	—	Policy
Gold (shared)	4 (SPEED 400)	No	—	—	Policy
KVM-2	2 vCPU	Yes	0.35x	504	Derived
FFStart / KVM-4	4 vCPU	Yes	0.67x	964	Measured
FFPower / KVM-8	8 vCPU	Yes	1.26x	1,814	Measured
KVM-16	16 vCPU	Yes	1.81x	2,606	Derived
Dedicated, 6 cores / 12 threads	6 cores	Yes	0.67x–1.26x	964–1,814	Derived, bracketed
Dedicated, 20 cores / 40 threads	20 cores	Yes	2 concurrent 8-core jobs	3,628	Derived, concurrency
Dedicated, 32 cores / 64 threads	32 cores	Yes	4 concurrent 8-core jobs	7,256	Derived, concurrency

The AHosting FFmpeg Encode Capacity Ladder — finished 1080p H.264 minutes per 24 hours at 100% duty, preset medium. Size to about 60% duty in practice.

How the Derived FFmpeg Server Requirements Rows Were Derived

Three assumptions carry the derived rows, and each is printed so you can disagree with it. Doubling from four to eight cores measured 1.88x, so the KVM-2 row divides the FFStart figure by that same factor. AHosting states that going from eight to sixteen returns only half as much again, so the KVM-16 row applies 1.44x to FFPower rather than another 1.88x. The bare-metal rows do not scale a single job at all; instead they count how many 8-core jobs fit, because a single encode stops using extra cores long before 20 of them. Above all, one thing these rows cannot model is clock speed: a 3.2 GHz bare-metal core and a virtualized core are not interchangeable, and the concurrency multiples are upper bounds rather than promises.

When Bare Metal Is the Answer

Two conditions push past the KVM range, and neither is single-job speed. The first is job count: a live channel plus a VOD queue is two sustained workloads competing for one machine, and past a point the only fix is more cores to divide between them. The second is the physical layout that comes with them. Kernel documentation notes that memory access by CPUs attached to the same node is faster and higher-bandwidth than access to remote nodes, so a dual-socket box is not two independent machines for one job that spans both. By contrast, it is close to two independent machines for two jobs pinned one per socket — which is the argument for a whole physical machine once your workload is genuinely several parallel pipelines rather than one large one.

Matching Your Queue to a Tier: FFmpeg Server Requirements by Workload

Four shapes cover most real pipelines, and each one turns FFmpeg server requirements into a single row. Each row multiplies daily source minutes by renditions, divides by a 60% duty target, and reads down the ladder to the first tier that clears it.

Workload shape	Source min/day	Renditions	Finished min/day	Capacity needed at 60% duty	Tier
Podcast, three 45-minute episodes a week	19 (audio)	1	Negligible	Below the first tier	Shared Gold, or KVM-2 if the queue is automated
Course platform, four 20-minute lectures a day	80	3	240	400	FFStart — clears at 964
VOD library, thirty 10-minute uploads a day	300	3	900	1,500	FFPower — clears at 1,814
One continuous 1080p live channel	1,440	1	1,440 at real time	Sustained 1.0x or better	FFPower minimum — FFStart runs at 0.67x and falls behind
Live channel plus a VOD queue	1,440 + 200	1 and 3	2,040	3,400	Dedicated, 20 cores — clears at 3,628

The Queue-to-Tier Table — worked examples in finished 1080p H.264 minutes. Audio-only work is far cheaper than video and is sized against the decode-only row of the measured table.

Run your own numbers below. The calculator uses the same measured constants and prints them, so nothing about the arithmetic is hidden.

Encode Capacity Calculator

Enter the queue you actually have. Every constant below is the measured AHosting figure for that codec, printed in the note so the arithmetic is auditable.

Source minutes per day

Renditions per source

Output

Duty cycle (%)

See what the FFmpeg plans allocate

One honest note on where this lands commercially. The measurement that anchors every row here was run on the plans we sell, and the tier that clears your FFmpeg server requirements without throttling is what the FFmpeg plans allocate: guaranteed vCPU, no cron time limits, and FFmpeg already built. Therefore the four- and eight-core rows are ours and measured; the rest is arithmetic from them, and the plan that clears your number is the one to order.

A Practical Checklist: Are Your FFmpeg Server Requirements Covered?

You have a daily figure in finished encode-minutes, not in uploads or gigabytes.
The figure includes every rung of your rendition ladder, plus thumbnails and preview clips.
You have measured your own throughput multiplier on a representative source, with your real command.
You have sized to roughly 60% duty, so a heavy day drains instead of accumulating.
Live work, if any, is sized on the peak and needs a sustained rate above 1.0x real time.
Your chosen tier is permitted to hold CPU for hours — that rules out every shared plan.
You have checked cores against threads on any bare-metal listing, not just the larger number.
Storage is sized for a working set rather than an archive, with object storage behind it if needed.
You know whether your codec is H.264 or HEVC, because HEVC needs roughly a quarter more capacity.
You have a queue, so nothing encodes inside a web request.

Frequently Asked Questions About FFmpeg Server Requirements

What are the FFmpeg server requirements for encoding 1080p video in 2026?

Specifically, they are the number of finished encode-minutes your queue produces each day, divided by the throughput a plan sustains. AHosting measured a 4 vCPU plan at 0.67x real time and an 8 vCPU plan at 1.26x on 1080p H.264, so a 4 vCPU machine finishes about 964 minutes of 1080p in a day and an 8 vCPU machine about 1,814. Work out your own daily figure first; the capacity ladder in this post then reads off which tier clears it.

What are the CPU and RAM requirements to run FFmpeg?

Specifically the CPU side is set by your daily output minutes, and on the AHosting plans the RAM arrives with the tier rather than being chosen separately. Measured 1080p H.264 throughput is 0.67x real time on the four dedicated vCPUs of FFStart, which ships 8 GB, and 1.26x on the eight vCPUs of FFPower, which ships 16 GB. Because encoding throughput scales with cores rather than with memory, size the tier on finished encode-minutes per day and let the memory follow it; in practice it is the number of concurrent jobs that consumes RAM, not a single encode.

FFmpeg server requirements on VPS vs dedicated hardware: which is right in 2026?

In practice a VPS is right until one machine can no longer run enough concurrent jobs, which is usually somewhere past 16 cores. A single encode stops using extra cores well before that point, so the reason to buy bare metal is job count and sustained live work, not single-job speed. Dedicated hardware also brings a second socket into play, and two sockets are not two independent machines.

Is shared hosting vs a VPS a real choice for FFmpeg encoding work?

Notably it is not a real choice for encoding, and the constraint is policy rather than arithmetic. Shared plans exist on the assumption that nobody holds a core for hours, so the execution-time limit stops a long encode part-way and leaves a truncated file that looks like a command error. Shared hosting handles probing, thumbnails, stream copies and short audio work perfectly well; sustained transcoding needs a machine you are allowed to saturate.

When do FFmpeg server requirements push you past AHosting's 8 vCPU FFPower plan?

Ultimately at the point where one machine cannot hold your live stream and drain your VOD queue at the same time. A continuous 1080p transcode consumes real-time throughput all day, and FFPower sustains about 1.26x real time, so a single live channel leaves roughly 374 finished minutes a day for everything else. Anything larger than that is a job-count problem, which is what a 20-core or 32-core machine solves.

Can a 4 vCPU plan hold a continuous 1080p live transcode at real time?

However tempting the price is, no. The measured 1080p H.264 rate on four dedicated vCPUs is 0.67x real time, which means the encoder falls a third of a minute behind for every minute of broadcast and never recovers. Eight vCPUs measure 1.26x, which clears real time with about a quarter of headroom. Live work is sized on the peak, never on the average.

How do I convert my encode queue into FFmpeg server requirements in core-hours?

First and foremost, count outputs rather than inputs. Take your daily source minutes, multiply by the number of renditions each source produces, and you have finished encode-minutes per day. Divide that by the throughput multiplier a tier sustains for your codec and resolution, then divide again by your target duty cycle. The result is the daily capacity the plan has to carry, and it is the only number that decides the tier.

What is the AHosting FFmpeg Encode Capacity Ladder and how do I read it?

Accordingly it is a table that puts every AHosting tier on one scale: guaranteed cores, whether sustained encoding is permitted at all, the 1080p throughput multiplier, and the finished 1080p minutes a tier clears in 24 hours. Two rows are measured on plans we sell and the rest are arithmetic from them, and every cell says which it is. Read down to the first row whose daily figure exceeds your own.

Do AHosting FFmpeg hosting plans meet the FFmpeg server requirements for HEVC output?

Indeed they do, with the caveat that HEVC costs noticeably more CPU than H.264. The same measured test put 1080p HEVC at 0.54x real time on four vCPUs and 0.88x on eight, against 0.67x and 1.26x for H.264. Both plans ship libx265 pre-built, so nothing needs compiling; the practical effect is that an HEVC queue needs roughly a quarter more capacity than the same queue in H.264.

Do FFmpeg server requirements change if I add a three-rung HLS ladder in 2026?

For example, a library of 100 source minutes a day becomes 300 finished minutes the moment you publish three variant streams instead of one. HLS master playlists reference several media playlists, each encoded at its own bit rate and resolution, and every rung is a separate encode. Adding a rung is therefore a capacity decision rather than a packaging one, which is why the multiplier belongs in the arithmetic before the tier is chosen.

September 8, 2026

AI Crawler Traffic Is Now a Hosting Cost: 65,044 Fetches, Measured

What AI Crawler Traffic Actually Is (And Why It Is Not One Thing)
- Indexing Crawlers and User-Triggered Fetchers Are Different Jobs
- Why That Distinction Decides What You Can Control
28 Days of AI Crawler Traffic, Measured on One Hosting Network
What an AI Crawler Fetch Actually Costs Your Plan
Why robots.txt Does Not Fix the Biggest AI Crawler Number
- What Perplexity's Own Documentation Says
- What robots.txt Still Does Control
AI Crawler Traffic vs. a Bot Flood: Which Problem Do You Have?
What AHosting Actually Ships for AI Crawler Load
A Practical Checklist for AI Crawler Traffic
Frequently Asked Questions About AI Crawler Traffic

TL;DR

AHosting logged 65,044 AI crawler fetches in 28 days against 298 Google clicks. Most of that load costs nothing, because a cached page consumes no entry process — and most of it cannot be blocked with robots.txt either, because 72% of it is user-triggered.

Every hosting blog now carries advice about AI crawler traffic, and almost all of it ends at the same instruction: edit your robots.txt. Over 28 days we counted what the AI crawlers actually did to one hosting network — 65,044 fetches — and then worked out what those fetches cost and which of them that instruction can reach. The answer to the second question is most of the advice does not apply to most of the traffic.

Listen: 65,044 assistant fetches, 79 visits back, and where the real cost sits. By Matt Chrust, Director of Business Development, AHosting.

Furthermore, the cost is not where the volume is. Most of those 65,044 requests were free, for a reason that has nothing to do with AI and everything to do with how a cached page is served. What follows is the measurement, the mechanism, and the part of the problem that is genuinely worth acting on.

What AI Crawler Traffic Actually Is (And Why It Is Not One Thing)

Notably, the phrase covers two populations that behave alike in a log file and differently in every way that matters. Separating them is the first step, and it is the step most write-ups skip.

Indexing Crawlers and User-Triggered Fetchers Are Different Jobs

Specifically, an indexing crawler is building a corpus. It arrives on a schedule of its own choosing, works through your site methodically, and stores what it finds for later. OpenAI’s crawler documentation describes exactly this split in its own products: GPTBot gathers content for model training, while OAI-SearchBot exists to surface pages in ChatGPT search results, and a site can allow one and refuse the other.

A user-triggered fetcher does something else entirely. Somebody asked an assistant a question a few seconds ago, the assistant decided your page might answer it, and the fetch happens live while that person waits. Perplexity’s crawler documentation draws the same line: PerplexityBot surfaces and links pages in search results, while Perplexity-User supports a specific action a person just took.

In practice, the log line looks identical. Both are a GET for an article, both come from a declared user agent, and both count once. The difference only appears when you ask what would happen if you tried to stop them.

Why That Distinction Decides What You Can Control

Indeed, robots.txt was written for the first population and not the second. RFC 9309 standardized the Robots Exclusion Protocol for automatic clients working through a site of their own accord, and the whole model assumes a crawler that fetches the file, reads the rules and then decides where to go next.

A fetch made because a person asked for it does not fit that model, and the vendors say so. Perplexity documents that its user-triggered agent generally ignores robots.txt rules, on the stated grounds that a user requested the page. Consequently, the largest category of AI crawler traffic in our own logs is also the category that a robots.txt edit does not reliably touch.

That gap is being worked on rather than merely complained about. The IETF has a working group, AI Preferences, building a vocabulary for expressing how content may be used by automated systems, precisely because the existing file cannot carry the distinction. Until that work lands, the honest position is that you have policy control over indexing and very little over live retrieval.

28 Days of AI Crawler Traffic, Measured on One Hosting Network

Ultimately, the argument above is only worth making if the numbers behind it are real. These come from AHosting server access logs for the 28 days from 4 August to 31 August 2026, grouped by declared user agent. They are ours, and nothing here is modeled or extrapolated.

The AHosting AI Crawler Load Table

Agent	Fetches, 28 days	Class	Reachable by robots.txt
Perplexity-User	38,743	User-triggered	No — vendor states it generally ignores it
ChatGPT-User	7,197	User-triggered	No — live browsing on a user request
Amazonbot	3,743	Indexing	Yes
ClaudeBot	3,503	Indexing	Yes
PerplexityBot	3,292	Indexing	Yes
OAI-SearchBot	2,519	Indexing	Yes
GPTBot	2,379	Indexing	Yes
Google-Extended	1,020	Indexing	Yes
Applebot	988	Indexing	Yes
Claude-User	936	User-triggered	No — live browsing on a user request
Bytespider	478	Indexing	Yes
meta-externalagent	246	Indexing	Yes
Total	65,044	46,876 user-triggered	18,168 reachable

The AHosting AI Crawler Load Table — AHosting.net server access logs, 4–31 August 2026 (28 days). Class assignment follows each vendor’s own published documentation.

Above all, read the last row first. Of 65,044 fetches, 46,876 came from the three agents their own vendors describe as acting on a live user request — 72% of it is user-triggered. The remaining 18,168 are indexing crawls, and those are the ones a robots.txt rule genuinely governs.

65,044 AI Crawler Fetches Against 298 Google Clicks

For example, put that total next to the search traffic from the same 28 days. Google Search Console recorded 52,662 impressions and 298 clicks for AHosting.net over the identical window. AI systems therefore read the site roughly 218 times for every visit Google search sent to it.

Interestingly, the raw scale is easy to misread as alarming. Spread across 28 days, 65,044 fetches average about 2,323 a day, or roughly 1.6 a minute — which no server notices as a rate. Volume alone is not the problem, and a post that stopped here would be selling a worry rather than describing one.

Similarly, one agent dominates to a degree worth naming. Perplexity-User alone accounts for 38,743 of the total, close to three-fifths of all AI crawler activity on the network, and it sits in the category that robots.txt does not reliably reach. Any policy that treats this as a single undifferentiated stream will therefore mostly regulate the smaller half.

What Came Back: 79 Assistant Referrals

By contrast, the return traffic over the same window was 74 referred visits from ChatGPT and 5 from Gemini. Seventy-nine visits, against 46,876 user-triggered reads. That works out at one referred reader for roughly every 593 pages an assistant fetched on somebody’s behalf.

Fortunately, that number is a starting point rather than a verdict. An assistant that answers a question without sending a click still puts the brand in front of the person asking, which is the whole argument of our guide to optimizing a WordPress site for AI search. What the ratio does establish is that nobody should assume this traffic pays for itself in visits.

Overall, the useful framing is a trade rather than a leak. You are giving up some server work and getting citations, brand presence and a small number of high-intent readers. Whether that trade is good depends entirely on what the server work costs, which is the next question and the one almost nobody answers.

What an AI Crawler Fetch Actually Costs Your Plan

Therefore the meaningful unit is not the fetch. It is the entry process, and the gap between those two things is where this entire topic gets misjudged.

Entry Processes, and Why a Cached Page Costs None

Accordingly, start with the definition rather than the intuition. CloudLinux documents an entry process as a limit that usually represents the maximum number of concurrent connections to Apache dynamic scripts, alongside SSH sessions and cron jobs running at the same time. The operative word is dynamic. An entry process is a slot held while PHP is running, not a counter of requests.

On AHosting a cached page costs zero entry processes, because LiteSpeed answers it at the server level and no PHP script is ever started. That is the same mechanism described in our write-up of server-level caching, and it is why the 65,044 figure is not a bill.

Consequently, an AI crawler reading your article pages behaves almost exactly like a visitor reading them from cache: it consumes bandwidth, it does not consume a concurrency slot, and it disappears from the constraint you actually pay for. Where a fetch does reach PHP, it holds one of those slots for as long as the request takes, and at that moment it is indistinguishable from a human.

Where the AI Crawler Cost Is Genuinely Concentrated

In particular, the cost lives on whatever you expose that caching does not cover. Internal search URLs run a database query per request and are almost never cached. Faceted or parameterized listing pages generate an effectively unlimited set of unique addresses, each one a cache miss by construction. Feeds, calendar archives and admin-ajax endpoints behave the same way.

Moreover, a crawler is far more likely than a human to find those paths, because it follows every link it can see rather than the two or three a reader would. A site with a crawlable faceted archive can hand an AI crawler thousands of distinct uncached URLs from a single category page.

Specifically, this is why the fix is usually a caching and crawl-surface audit rather than a robots.txt edit — and the two get confused because both are edits to the same kind of file. Where an entry-process ceiling is genuinely being hit, the diagnosis in our explanation of the 508 resource limit error applies unchanged, since a crawler-driven ceiling and a traffic-driven one produce the identical symptom.

Notably, an appropriate Cache-Control policy also determines how often a well-behaved fetcher comes back for something it already has, which quietly reduces the indexing half of the load without refusing anybody anything.

AI Crawler Entry-Process Headroom by Plan Tier

Shared tier	Entry processes	Physical memory	What that means for crawler load
Bronze	20	1 GB	Fine for a cached content site; tight if search URLs are crawlable
Silver	30	2 GB	Comfortable headroom once articles are served from cache
WooStart	40	3 GB	Sized for cart and checkout paths, which are uncached by design
Gold	50	4 GB	Room for a large uncached surface alongside human peak

AHosting shared plan entry-process allocations, verified against the live server configuration on 31 August 2026. The ceiling is shared between crawler and human requests.

In other words, bot traffic consumes entry processes only where your cache does not cover it, and that ceiling is what the plan tiers set. If your uncached surface is small, crawler load is not the reason to move tier. If it is large and genuinely necessary, the WordPress hosting tiers are where that headroom comes from, and the estimator further down turns your own numbers into the comparison.

Why robots.txt Does Not Fix the Biggest AI Crawler Number

That said, none of the above means robots.txt is useless. It means it is a policy instrument that is widely mistaken for a load control, and the difference shows up precisely where the volume is.

What Perplexity’s Own Documentation Says

Fortunately, this does not require inference, because the vendor states it plainly. Perplexity’s crawler page says that since a user requested the fetch, that fetcher generally ignores robots.txt rules. Perplexity-User is 38,743 of our 65,044 fetches.

Similarly, the pattern is not unique to one company. Live-browsing agents across the sector are framed as acting for a person rather than as autonomous crawlers, and the exclusion protocol has never claimed authority over a request a human initiated. Google’s own crawler reference makes the same three-way split between common crawlers, special-case crawlers and user-triggered fetchers.

Consequently, a robots.txt file that disallows every AI agent you can name will still leave the majority of this traffic arriving. Believing otherwise is the specific failure mode this article exists to correct, and it is expensive only in the sense that it stops people looking at the thing that would actually help.

What robots.txt Still Does Control

However, the 18,168 indexing fetches are a different matter, and there the file works exactly as documented. Blocking a training crawler stops that crawler. Allowing a search crawler is what keeps you eligible to be cited, and OpenAI notes that a site opted out of OAI-SearchBot will not appear in ChatGPT search answers.

For example, AHosting.net runs the split deliberately rather than by default. The live file allows GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended and Applebot-Extended, and disallows CCBot, Bytespider, TikTokBot, anthropic-ai, cohere-ai, meta-externalagent and Amazonbot. Agents that cite and link are welcome; agents that only harvest are not.

Additionally, the file carries a Content-Signal declaration reading search=yes, ai-train=no, ai-input=yes — a machine-readable statement that the site may be indexed for search and used to answer a live question, but not used as training data. Notably, that is a statement of terms rather than an enforcement mechanism, which is the right way to think about the whole file.

AI Crawler Traffic vs. a Bot Flood: Which Problem Do You Have?

In contrast to everything above, some sites really are being hurt by automated traffic — and when they are, an AI crawler is usually not what is doing it. The two present differently enough that a few minutes in the access log settles which one you have.

Signal	Legitimate AI crawler traffic	Abusive bot flood
Target	Article and category pages, spread across the site	One endpoint hit repeatedly — login, XML-RPC, search
Rate	Steady; 65,044 fetches over 28 days averaged 1.6 a minute	Bursty; thousands of requests an hour against one URL
Identity	Declared agent with vendor-published IP ranges you can verify	Spoofed or absent agent, unverifiable addresses
Cache behavior	Mostly served from cache, so mostly free	Deliberately targets uncached and authenticated paths
Correct response	Audit the uncached surface; set policy in robots.txt	Rate-limit or block at the edge

How to tell an AI crawler apart from an abusive bot flood, from AHosting support cases and the access-log patterns behind them.

Therefore the diagnosis changes the action completely. An XML-RPC flood is handled the way our guide to stopping one describes, at the edge and quickly. AI crawler load is handled by looking at what you leave uncached, which is slower, duller and permanent.

Above all, verify before you act. Every major vendor publishes the IP ranges its agents use, so an agent string claiming to be a well-known crawler can be confirmed or rejected rather than assumed — and traffic impersonating a crawler is by definition the second column, not the first.

What AHosting Actually Ships for AI Crawler Load

Specifically, three things carry this on our stack, and none of them was built for AI. Server-level LiteSpeed caching removes the entry-process cost from every page it covers. The per-tier entry-process allocation sets the ceiling that the uncached remainder competes for. And the access logs are the only place any of this can be measured rather than guessed at.

Moreover, the estimator below is the arithmetic, not a product pitch. Put in your own daily fetch count, your honest cache-miss share and your tier, and it returns how much of that ceiling the crawler load is actually holding. Most sites that run it discover the answer is almost none, which is the useful finding.

AI Crawler Load Estimator

Give it your daily AI fetch count, the share of those that miss your cache, and your plan tier. It returns the entry processes that load actually occupies at peak, and whether the tier has room for it.

AI crawler fetches per day

Share of those fetches that miss the cache

Plan tier

Arithmetic over your own numbers, not a prediction. It assumes a 400 ms average dynamic response and a peak hour carrying four times the average rate, and it counts crawler load only – your human traffic occupies the same ceiling alongside it.

Compare the shared hosting tiers

Ultimately, where the estimator says the load is binding, the constraint is real and the options are the ones it names: reduce what is reachable and uncached, or raise the ceiling. For a site whose uncached surface is genuinely necessary — a large store, a busy membership area, an application rather than a publication — that ceiling stops being shared at all on a VPS plan. Where the pressure is coming from human concurrency instead, the PHP worker calculation sizes the same ceiling from the other direction.

A Practical Checklist for AI Crawler Traffic

Finally, work through this in order. Every item is answerable from your own logs and your own configuration, and the sequence matters — a policy decision made before the measurement is a preference rather than a diagnosis.

Access logs grouped by user agent over a fixed window, so the fetch count is measured rather than sensed.
User-triggered agents separated from indexing agents before any total is quoted.
Referred visits from assistants counted over the same window, so the return side is known too.
Cache hit rate established for article pages, since that is what decides whether the load costs anything.
Uncached surface listed explicitly: search URLs, faceted parameters, feeds, calendar archives, ajax endpoints.
Anything on that list that does not need to be crawlable removed from the crawl surface.
Entry-process ceiling for the current tier known, and the peak-hour crawler share estimated against it.
robots.txt treated as a policy statement about indexing and training, never as a load control.
Agent identity verified against published vendor IP ranges before anything is blocked.
The decision revisited quarterly, because agent behavior and volumes are changing faster than the standards are.

In fact, the discipline this asks for is modest. Count what arrives, split it by whether a person asked for it, find out how much of it reaches PHP, and only then decide anything. On the network measured here that sequence turned a number that looks like a crisis into a caching question with a short answer, and it will do the same for most sites that run it honestly.

Frequently Asked Questions About AI Crawler Traffic

Do AI crawler visits actually cost me anything on shared hosting in 2026?

Typically, only where the request reaches PHP. A page served from the server-level cache never starts a dynamic script, so it consumes no entry process and costs the plan nothing measurable. The cost appears on the paths caching does not cover, which is a much smaller and much more specific list than the raw fetch count suggests.

AI crawler vs search engine crawler: what is the difference for my server?

In practice, the load behaves the same and the control does not. A search crawler is building an index and comes back on its own schedule, so it obeys robots.txt and it can be slowed. A user-triggered AI crawler arrives because a person asked a question a moment ago, and several vendors state that this class of fetcher does not treat robots.txt as binding.

Can I block AI crawler traffic with robots.txt, and does it work?

Specifically, it works for the indexing half and not reliably for the other. Perplexity’s own documentation says its user-triggered fetcher generally ignores robots.txt rules because a person requested the page. Blocking is therefore a policy statement about training and indexing rather than a load control, and treating it as a load control is where most advice on this topic goes wrong.

What is the AHosting robots.txt policy on AI crawler access in 2026?

Notably, AHosting allows the assistants that cite and link, and blocks the ones that only harvest. The live file explicitly allows GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended and Applebot-Extended, and disallows CCBot, Bytespider, TikTokBot, anthropic-ai, cohere-ai, meta-externalagent and Amazonbot. It also carries a Content-Signal line reading search=yes, ai-train=no, ai-input=yes.

User-triggered fetches vs indexing crawls: which one should I worry about?

Ultimately, the user-triggered half, because it is both larger and less controllable. Across 28 days on AHosting the three user-triggered agents accounted for 46,876 of 65,044 total fetches. That is the portion that arrives in response to a real question, cannot be scheduled away, and is the only portion with any chance of sending a reader back.

How many entry processes does an AI crawler fetch consume on a cached page?

Fortunately, none. CloudLinux defines an entry process as a concurrent connection to a dynamic script, and a page returned by the server-level cache never invokes one. Where the fetch lands on an uncached path, though, it consumes exactly the same entry process a human visitor would, and it competes for the same ceiling.

Which AHosting plan tier gives enough entry processes for heavy AI crawler traffic in 2026?

Accordingly, the answer depends on your uncached surface, not on the fetch count. The shared tiers allocate 20, 30, 40 and 50 entry processes for Bronze, Silver, WooStart and Gold respectively, verified against the live server configuration. A site whose cache covers its article pages rarely needs a larger tier for crawler load alone; a site with heavy search or faceted URLs often does.

How many visitors does AI crawler traffic actually send back to a hosting site?

Indeed, far fewer than the read volume implies. The same 28-day window that recorded 65,044 AI fetches on AHosting recorded 74 referred visits from ChatGPT and 5 from Gemini. That ratio is the honest starting point for any conversation about whether to allow, throttle or block, and it is a number most sites have never worked out.

How do I measure AI crawler load in my own server access logs?

For example, group raw access-log requests by user agent over a fixed window, then separate the user-triggered agents from the indexing ones before you total anything. The vendors publish the exact agent strings and their IP ranges, so verification is possible rather than guesswork. Measuring first is what stops a policy decision being made on an impression.

How does AHosting tell an AI crawler apart from an ordinary bot flood?

By contrast, a flood concentrates on one endpoint and a crawler spreads across content. Automated abuse hammers a login form, an XML-RPC endpoint or a search parameter thousands of times an hour from unverifiable addresses. Legitimate AI crawler traffic identifies itself, publishes its address ranges, and reads article pages, which is why the two need different responses.

September 4, 2026

FFmpeg Threads and CPU Allocation: How Many Threads Actually Help

Why More FFmpeg Threads Stop Making Encodes Faster
- The Two Ceilings, and Only One of Them Is Your CPU
What Actually Sets Your Useful FFmpeg Thread Count
The AHosting FFmpeg Thread Budget
- Two Assumptions Behind the FFmpeg Threads Column
Jobs, Not Threads: The Split That Uses the Box You Paid For
When FFmpeg Threads Are Not Your Problem At All
What Guaranteed vCPU Changes
A Practical Checklist: Setting FFmpeg Threads on Your Plan
Frequently Asked Questions About FFmpeg Threads

TL;DR

Useful FFmpeg threads are capped by the video, not by your core count. At 1080p that cap is about four, so spare vCPU buys a second job rather than a bigger thread number.

You moved the work onto a server with eight dedicated cores, set FFmpeg threads to eight to match, and the encode finished barely faster than it did on four. Nothing is throttling you, the machine is genuinely yours, and half of it looks busy doing very little. That is not a misconfiguration, and it is not a bad plan. It is the point at which the number of cores stops being the number that matters.

Listen: why matching thread count to core count stops working, and what to run instead. By Matt Chrust, Director of Business Development, AHosting.

Specifically, the thing that decides how many workers an encoder can keep busy is the video, not the processor. A codec parallelises by splitting the picture into pieces that can be worked on independently, and there are only so many pieces in a frame. Once you have a worker for each one, another worker has nothing to pick up. The codec projects publish this openly, in numbers, and almost nobody writing about encoding performance quotes them.

Therefore this article does two things. It gives you the ceiling for your output resolution and the arithmetic that turns it into a per-job thread count, and it shows what to do with the cores that ceiling leaves over. If your encode is slow on a shared plan rather than a server of your own, start with the three-number diagnostic for slow FFmpeg encoding instead, because a capped container changes the answer completely. For the buying side of the question, our guide to FFmpeg hosting for video creators covers what to look for before you have a server at all.

Why More FFmpeg Threads Stop Making Encodes Faster

In practice, extra threads stop helping at the point where the encoder runs out of independent work to hand them. That point arrives well before most people expect, and it has nothing to do with how much CPU you bought. An encoder cannot invent parallelism that is not in the source.

Notably, the default hides this. Left alone, FFmpeg picks a thread count from the machine, so on an eight-core server you get eight workers whether or not there is eight workers’ worth of work. The command looks correct, the process starts, every core shows activity in a monitor, and the result is a modest gain over half as many FFmpeg threads. Nothing reports the waste, because from the operating system’s point of view nothing is wrong.

The Two Ceilings, and Only One of Them Is Your CPU

Fortunately, the situation resolves into two numbers. One is familiar: the cores your plan allocates, a hard limit on how much CPU time you can spend per second. The second is the one that gets missed: the number of threads the codec can actually put to work on a frame of a given size. Your per-job thread count is the lower of the two, and which one is lower changes the advice completely, because setting FFmpeg threads to your core count is only correct when the cores are the smaller number.

By contrast, most tuning guidance addresses only the first. Our own knowledge base article on FFmpeg presets, CRF and command-level tuning is the right reference once you know which ceiling binds you, and it covers the levers that genuinely reduce the CPU cost of an encode. This article is upstream of it: before choosing a preset, work out whether the machine or the material is the constraint, because that decides whether you are looking for a faster command or a different way to run it.

What Actually Sets Your Useful FFmpeg Thread Count

Frame Geometry Caps Useful FFmpeg Threads, Not Your Core Count

Ultimately, the cap comes from how the codec divides a picture. Google publishes recommended settings for VP9 video on demand, and the table is a resolution ladder rather than a hardware one: 640×360 and 640×480 get two threads, 1280×720 and 1920×1080 get four, and 2560×1440 and 3840×2160 get eight. The figure moves with frame size, and it stops moving well below the core count of an ordinary server. The same page notes that “there is limited value to multiple threads when the output frame size is very small.”

Similarly, the WebM project states the general recommendation as the number of real cores minus one, and explains the mechanism plainly: rows of macro-blocks are encoded simultaneously on different threads. Rows are the unit of parallelism, so a frame with few rows has few pieces to hand out. That is why a 4K encode can keep eight threads busy while a 480p encode of the same length cannot keep three busy, on identical hardware, with an identical command.

x265 Picks Its Own Frame Threads and Warns You Off More

Interestingly, the clearest statement of the problem comes from an encoder that already solves it for you. The x265 project allocates one thread per CPU core by default and auto-detects a frame-thread count from the core count — two frame threads at four cores, three at eight, five at sixteen. It then warns against overriding that upward, because frame threads “each allocate a large amount of memory” and the reference lag between frames limits how much of the work is genuinely independent.

Above all, note how the project phrases the consequence: beyond the auto-detected count you get limited benefit, and “often the extra frame encoders reduce performance.” Not the same speed for more memory, but slower. An encoder shipping a conservative default and a written warning against raising it is a strong signal that the received wisdom about matching threads to cores is wrong.

Why the Scheduler Makes Extra FFmpeg Threads Cost You

Consequently, threads you cannot feed are not free. The Linux scheduler documentation describes its model as an ideal CPU running every task in parallel at 1/nr_running speed — as the number of runnable tasks rises, each one’s share falls proportionally. Sixteen threads on eight cores do not get sixteen cores’ worth of time. They get eight cores’ worth, cut into sixteen thinner slices, with the switching between them charged to you.

For example, the same counting error shows up elsewhere on a server. Our post on how many concurrent users WordPress shared hosting can handle works through the identical mistake in PHP workers: raising the worker count past what the CPU can serve does not raise throughput, it just spreads the same capacity thinner and adds contention. Encoders are the same arithmetic with a different unit of work.

The AHosting FFmpeg Thread Budget

Accordingly, the two ceilings combine into one table. The AHosting FFmpeg Thread Budget below sets each plan’s effective cores against the useful thread ceiling for 1080p output, and reads off the per-job thread count and the split that follows from it. Shared tiers take their core figure from the CloudLinux CPU speed allocation, where 100 percent is one core; the FFmpeg plans take theirs from the vCPU on the plan page.

AHosting tier	Effective cores	Useful threads per 1080p job	The split that follows
Bronze shared	1	1	1 job at 1 thread
Silver shared	2	2	1 job at 2 threads
WooStart shared	3	3	1 job at 3 threads
Gold shared	4	4	1 job at 4 threads
FFStart	4 vCPU, guaranteed	4	1 job at 4 threads
FFPower	8 vCPU, guaranteed	4 (capped by the codec)	2 jobs at 4 threads

The AHosting FFmpeg Thread Budget. Effective cores are published allocations; the 1080p ceiling is the VP9 VOD recommendation for that frame size. Arithmetic over published figures, not benchmark data.

Read the last row first, because it is where the argument lands. FFPower is the only tier whose core count exceeds the codec ceiling, which means it is the only tier where adding threads to a single job cannot spend what you are paying for. Everywhere above it, one job at the full thread count already uses the plan. The shared rows come from the shared plan allocations, and they carry a caveat the FFmpeg rows do not: a container reaches its cap only while its neighbors leave it free.

Two Assumptions Behind the FFmpeg Threads Column

Two assumptions are printed rather than buried. The ceiling column is for 1920×1080; at 1440p and above it rises to eight and the FFPower row becomes one job at eight threads. And every figure here is arithmetic over published numbers, not a measurement — we have benchmarked no encodes and are not implying otherwise.

Jobs, Not Threads: The Split That Uses the Box You Paid For

That said, a ceiling is only useful if it tells you what to do with the headroom. The answer is that spare cores go to another job, because a second file arrives with a full set of frames of its own and none of the dependencies that limit the first.

Why One Job at Eight FFmpeg Threads Leaves an 8 vCPU Box Idle

Indeed, the diagram is the whole finding. On eight vCPU encoding 1080p, a single job with eight threads has genuine work for about four of them; the rest wait on frame dependencies and get scheduled anyway. Two concurrent jobs at four threads each have eight threads’ worth of real work, because file B’s frames do not have to wait for file A’s.

In fact, this is why throughput and latency pull in opposite directions here. One file that has to be finished as fast as possible should take every thread the codec can use and no more. A queue of twenty files should be run as several concurrent jobs, because total elapsed time for the queue is what you are minimising, and that is a throughput problem rather than a latency one.

Running the Split with xargs

Typically, you do not need a job runner to do this. The xargs -P option runs up to that many processes at a time, and it is present on every Linux server you are likely to meet. Piping a file list into it with -P set to your job count and -threads set to your per-job figure is the entire implementation.

However, the detail of doing that safely — output naming, failure handling, keeping a long queue from swamping the box — is its own subject, and our knowledge base covers it in how to run FFmpeg jobs in parallel without overloading. What this article contributes is the number to put after -P, which that article reasonably leaves to you. The planner further down produces both figures and the command line that carries them.

Adaptive Bitrate Ladders Are the Clearest Case

For example, a five-rung ladder encodes one source at five bitrates, and the rungs do not depend on each other at all. Research on multi-representation encoding treats this as the standard approach: with multi-core CPUs, multiple representations of the same content can be encoded in parallel. Five concurrent single-threaded encodes on four cores will finish a ladder sooner than five four-threaded encodes run one after another.

Shape of the work	What you are minimising	The split	Why
One file against a deadline	Elapsed time for that file	All useful threads on one job	Latency. Spare cores have no second source of work.
A batch or queue of files	Elapsed time for the whole queue	Cores divided by the ceiling	Throughput. Each file brings its own frames.
An adaptive bitrate ladder	Elapsed time for the full ladder	One job per rendition	The renditions are independent encodes of one source.
A heavy filter graph	Elapsed time for that file	Fewer jobs, more threads	Filtering is a separate stage with its own threading.

The Jobs-vs-Threads Decision Table. Match the split to what you are minimising, not to the core count.

Above all, batch work is where the difference compounds rather than appearing once. A ladder or a nightly queue runs the same arithmetic every night, and the gap between a saturated box and a half-used one is the whole reason sustained encoding workloads justify their own hardware rather than sharing capacity with anything else.

When FFmpeg Threads Are Not Your Problem At All

Honestly, none of this applies if something else is capping you first, and the failure looks identical from the outside. An encode that is slow because a container limits CPU speed does not get faster from a better thread split, because the constraint is the total CPU time you are permitted rather than how you divide it.

Therefore check that before you act on anything above. The three-number diagnostic in the previous post in this series separates a throttled container from a disk bottleneck from a genuinely single-threaded encode, and it costs one timed run. If it tells you that you are throttled, the split in this article is the right plan for after you move, not a fix for where you are.

Similarly, storage can be the real limit. A job reading and writing over a network mount will show idle cores no matter how the threads are arranged, and adding concurrent jobs makes it worse rather than better by putting more pressure on the same device. Where the diagnosis points at the plan rather than the command, no arrangement of FFmpeg threads recovers it, and the shared hosting versus VPS comparison and the VPS plan range set out what changes and what does not.

What Guaranteed vCPU Changes

In particular, a thread plan is only worth making if the cores it assumes are actually yours for the duration. On a shared container the allocation is a share of a core that you reach when the neighbors are quiet, so a split calculated against four effective cores can find two on a busy evening. The plan is not wrong; the input moved.

Specifically, that is what the FFmpeg plans allocate. FFStart ships four vCPU and FFPower eight, both described on the plan page as guaranteed and unthrottled, with no cron time limits — so a six-hour batch is not slowed as an allowance runs down or cut off when a wall-clock limit arrives. Encoding the way this article describes needs CPU that stays where you put it, and that is the difference the plans are actually selling.

Furthermore, both plans ship FFmpeg and FFprobe pre-built with full root and SSH access, on Ubuntu 24.04.3 LTS with CloudPanel by default, and cover H.264, H.265, VP9 and AV1 with HLS and DASH output. Work out your own split first with the planner below, then check it against what each tier can hold, since the plan decides the cores and the cores cap the FFmpeg threads.

FFmpeg Job and Thread Planner

Give it the cores you have, the resolution you are writing out, and the shape of the work. It returns the per-job thread count, how many jobs to run at once, and the command that runs them.

Cores or vCPU available

Output resolution

Shape of the work

Arithmetic over published figures: the ceiling is the VP9 VOD recommendation for that frame size, and the core count is yours. It is a starting point to measure from, not a prediction of encode time.

See the FFmpeg hosting plans

A Practical Checklist: Setting FFmpeg Threads on Your Plan

Finally, work through this in order. Each item is answerable from the numbers this article has produced, and the sequence matters — a split calculated before the ceiling is known is a guess with arithmetic attached to it.

Throttling ruled out first, with a timed run, before any thread number is chosen.
Output resolution written down, since that is what sets the ceiling.
Codec ceiling read off for that resolution: two below 720p, four at 720p and 1080p, eight above.
Effective cores known from the plan allocation rather than from the processor count reported by the machine.
Per-job thread count set to the lower of those two figures, never to the higher.
Work classified as one deadline file, a queue, or a ladder, because each takes a different split.
Leftover cores assigned to concurrent jobs rather than to a larger thread number.
Source and destination confirmed to sit on local storage before concurrency is raised.
The chosen split timed once against the previous arrangement, so the change is measured rather than assumed.

Overall, the discipline this article asks for is small: read one published ceiling, compare it against one allocation, and spend the difference on jobs instead of on FFmpeg threads. That is a few minutes of arithmetic, and on an eight-core box running routine 1080p work it is the difference between using half the machine and using all of it.

Frequently Asked Questions About FFmpeg Threads

Does setting FFmpeg threads to 16 speed up a 1080p x264 encode on 8 vCPU?

Typically, no, and it can cost you a little. The useful thread count at 1080p is set by how the codec divides the frame, not by how many cores you own, and Google publishes four threads as the recommended figure at that resolution. Threads beyond the point the encoder can use still get scheduled, which spends CPU on switching between them rather than on encoding. The budget table below gives the ceiling for each AHosting tier.

How many threads should I use for FFmpeg encoding in 2026?

Specifically, start at the lower of two numbers: your available cores, and the useful ceiling for your output resolution. At 720p and 1080p that ceiling is four; at 1440p and above it rises to eight. The WebM project puts the general recommendation at the number of real cores minus one. Anything above the lower of those two figures buys scheduling overhead rather than speed.

How many FFmpeg threads can an AHosting FFStart plan actually use in 2026?

Notably, FFStart ships four vCPU, described on the plan page as guaranteed and unthrottled, so four is both the core count and the practical ceiling for a single 1080p job. One encode at four threads therefore uses the whole plan. Above 1080p the codec can use more threads than the plan has cores, which makes four the binding limit rather than the codec.

FFmpeg threads vs parallel jobs: which finishes a batch of encodes faster?

In practice, parallel jobs win once your core count exceeds the codec’s useful thread ceiling. A single job cannot spend cores the encoder has no work for, whereas a second independent job has its own frames to divide and starts using them immediately. Below the ceiling the two are equivalent, which is why the crossover lands at eight cores for ordinary 1080p work.

AHosting FFStart vs FFPower: how many parallel jobs and FFmpeg threads each in 2026?

Ultimately, FFStart’s four vCPU suit one 1080p job at four threads, while FFPower’s eight vCPU suit two concurrent jobs at four threads each. That difference is the whole argument for the larger plan on batch work: the second job is what converts the extra four vCPU into finished files. Both plans advertise guaranteed, unthrottled vCPU and no cron time limits.

Why does raising the x265 frame thread count sometimes reduce performance?

Fortunately, the x265 project states this outright rather than leaving it to be discovered. Frame threads each allocate a large amount of memory, and the reference lag between frames limits how much genuine parallelism is available, so beyond the auto-detected count the extra frame encoders often reduce performance. The encoder already reads your core count and picks a figure from it.

What is the FFmpeg thread budget, and how do I calculate mine?

Accordingly, the thread budget is two numbers compared: the cores your plan allocates, and the useful thread ceiling for your output resolution. The lower one is your per-job thread count, and the cores left over are what you fill with a second job rather than with more threads. The named table below works this through for all six AHosting tiers.

What does the FFmpeg threads option actually control during encoding?

Indeed, it controls how many workers the encoder is permitted to start, not how much parallel work exists for them to do. The available work comes from the video itself, through the rows, tiles and frames the codec can process independently. Where the option is left at its default it resolves to the machine’s processor count, which is why it so often exceeds what the content can use.

How should I set FFmpeg threads for a five-rung HLS ladder on 4 vCPU?

For example, run the five renditions as five concurrent jobs at one thread each rather than five jobs in sequence at four threads. Each rendition is an independent encode of the same source, so the renditions supply the parallelism the frames cannot. Research on multi-representation encoding treats parallel renditions on multi-core CPUs as the standard approach for exactly this reason.

Does AHosting FFmpeg hosting throttle vCPU during long encodes in 2026?

Additionally, no: the FFStart and FFPower plan pages state guaranteed, unthrottled vCPU and no cron time limits, so a long encode is not slowed or cut short by an allowance running out. That is the difference from a shared container, where CPU speed is capped as a share of a core. Which situation you are in decides whether this article or the diagnostic in the previous post applies.

September 3, 2026

OV SSL vs DV: What the Extra Money Actually Buys

What an OV SSL Certificate Actually Asserts — and What It Does Not
- Four Certificate Types, Not Three
- The Sentence the Rulebook Puts in Its Own Profile Section
OV SSL Factor 1: The Browser Stopped Showing the Difference in 2019
OV SSL Factor 2: The Validity Clock Is 200 Days and Falling
- Why the Two Reuse Clocks Disagree
- What Ballot SC102 Took Away From EV in July 2026
OV SSL Factor 3: The Premium Feature Is the One That Blocks Automation
What Each Certificate Type Is Actually Required to Contain
The Reissuance Arithmetic: What an OV SSL Certificate Costs in Labor
When an OV SSL Certificate Is Genuinely the Right Call
- eIDAS, QWACs, and the One Place Identity Is Legally Required
- Procurement Checklists, and How to Answer One Without Overbuying
What Our Support Queue Says About OV SSL and Certificate Types
Which Certificate Type Does Your Site Actually Need?
A Practical Checklist Before You Buy an OV SSL Certificate
Frequently Asked Questions About OV SSL Certificates

TL;DR

An OV SSL certificate proves the same thing about your domain as a free DV one. The rulebook says so, browsers stopped displaying the difference in 2019, and the organization name is what you are actually buying.

Every hosting control panel now hands out a free certificate, and every certificate authority still sells a more expensive one. The upgrade is usually described in the language of trust: a DV certificate proves you control a domain, while an OV SSL certificate proves a real organization stands behind it. That description is accurate. What it leaves out is that the body writing the rules for every public certificate authority has already stated, in the section of its own rulebook that defines these certificates, that the two are equivalent for the job a certificate does on the wire.

Listen: what an OV SSL certificate actually asserts, why browsers stopped displaying the difference in 2019, and how the 200-day validity ceiling changed the arithmetic. By Matt Chrust, Director of Business Development, AHosting.

This post is the reassessment rather than the explainer. It sets out what the standards actually require, what changed in 2026, and the four situations where paying more still earns its cost. For the neighboring question of what a free certificate includes and why renewal quietly fails, see our guide to what free SSL and domain management actually covers.

What an OV SSL Certificate Actually Asserts — and What It Does Not

An OV SSL certificate asserts one thing a DV certificate cannot: a verified legal entity, placed in the certificate subject and checked by the issuing authority against business records. Everything else about the two certificates is the same. Consequently, the useful question is not which is stronger but who reads that entity name, and how often.

Four Certificate Types, Not Three

Most explainers list three tiers. In fact the CA/Browser Forum Baseline Requirements define four subscriber certificate profiles, each asserting a fixed Reserved Certificate Policy Identifier. Individual Validated sits alongside the familiar three and names a natural person rather than a company. Notably, that identifier is the only part of this subject a buyer can verify without taking a reseller at their word.

The Sentence the Rulebook Puts in Its Own Profile Section

Directly beneath the table listing those four types, the Baseline Requirements add a note: “Although each Subscriber Certificate type varies in Subject Information, all Certificates provide the same level of assurance of the device identity (domain name and/or IP address).” In other words, the organization that certificate authorities collectively write their own rules through has recorded that the tiers are equivalent for identifying the server you connected to. No certificate authority markets that sentence, and it is the single most load-bearing fact on this page.

OV SSL Factor 1: The Browser Stopped Showing the Difference in 2019

For years the argument for validation tiers rested on what a visitor would see. That argument ended in September 2019. Chrome 76 displayed an Extended Validation badge beside the URL; Chrome 77 moved it into the Page Info panel behind the lock icon, where essentially nobody looks. Apple had made the equivalent change to Safari a year earlier.

Furthermore, the Chromium security team published its reasoning rather than leaving it to be inferred. Their documented rationale for moving the EV indicator states that “Users do not appear to make secure choices (such as not entering password or credit card information) when the UI is altered or removed, as would be necessary for EV UI to provide meaningful protection.” That is a measured finding from a field experiment, not an opinion about design. Therefore any pitch resting on visitor-visible trust is describing a browser that has not existed for seven years.

OV SSL Factor 2: The Validity Clock Is 200 Days and Falling

Meanwhile the operational ground shifted underneath every validation tier at once. Ballot SC081v3 passed in April 2025 and wrote a reduction schedule into the Baseline Requirements. Certificates issued before 15 March 2026 could run 398 days. From that date the ceiling is 200 days; from 15 March 2027 it is 100 days; from 15 March 2029 it is 47. Above all, these limits apply to every subscriber certificate equally, so buying a higher tier buys no relief from them.

Why the Two Reuse Clocks Disagree

Interestingly, the schedule moves two clocks at different speeds, and the gap between them is the whole operational story of an OV SSL certificate. Subject Identity Information validation data may be reused for 398 days. Domain Name and IP Address validation data may be reused for 200 days today, 100 from March 2027, and just 10 from March 2029. As a result, the organization vetting you paid for stays valid for roughly a year while the certificate carrying it must be replaced at least twice inside that same year.

What Ballot SC102 Took Away From EV in July 2026

Six weeks before this post was written, ballot SC102 was adopted and quietly removed the last places where Extended Validation had rules of its own for the domain half of the job. The EV Guidelines had carried a hardcoded 398-day domain data reuse period and their own validity text; both now simply point at the Baseline Requirements. The ballot also dropped the EV-only registrant re-check against WHOIS and RDAP. Accordingly, EV and DV are now validated against the domain by the same procedures on the same clock.

OV SSL Factor 3: The Premium Feature Is the One That Blocks Automation

Put those two facts together and the commercial logic inverts. The feature that makes a certificate premium is a human checking business records, and a human checking business records is precisely what cannot be automated. Let’s Encrypt states the position plainly: it does not offer organization or extended validation “primarily because we cannot automate issuance for those types of certificates.”

That was a defensible trade when a certificate lasted three years. Currently it is a commitment to a manual vetting pass at least twice a year, rising toward eight times a year once the 47-day ceiling arrives. Our own product page quotes EV issuance at one to three business days. Multiply that by the reissuance cadence rather than by a single purchase, and the real price of the tier becomes visible. Meanwhile the free alternative on every AHosting shared hosting plan is issued and renewed by cPanel AutoSSL, which “automatically installs domain-validated SSL certificates” and uses Let’s Encrypt as its default provider.

What Each Certificate Type Is Actually Required to Contain

Below is the profile the Baseline Requirements impose on each of the four types, reduced to the parts a buyer can act on. Specifically, the policy identifier is machine-readable: open any certificate, find its certificate policies extension, and the value tells you what you were sold regardless of what the invoice called it.

Type	Policy identifier	Organization name in subject	Domain validated by	Assurance of device identity
Domain Validated (DV)	2.23.140.1.2.1	Forbidden — any attribute beyond country and a deprecated common name must not be present	Baseline Requirements domain control methods	Same
Individual Validated (IV)	2.23.140.1.2.3	A verified natural person, with locality	Baseline Requirements domain control methods	Same
Organization Validated (OV)	2.23.140.1.2.2	A verified legal entity, with country and locality	Baseline Requirements domain control methods	Same
Extended Validation (EV)	2.23.140.1.1	A verified legal entity under the EV Guidelines, with no placeholder characters permitted	Baseline Requirements domain control methods, since ballot SC102	Same

The Four Subscriber Certificate Profiles. Source: CA/Browser Forum Baseline Requirements, sections 7.1.2.7.1 through 7.1.2.7.5. The final column is quoted from the standard itself.

The Reissuance Arithmetic: What an OV SSL Certificate Costs in Labor

Price comparisons treat a certificate as an annual purchase. That framing expired on 15 March 2026. Ultimately the cost that matters is issuance events per year multiplied by the human effort each one demands, and only one of those two numbers is falling.

Period	Maximum validity	Domain data reuse	Reissues per year	Automated DV effort	OV or EV effort at 1–3 business days per pass
Until 14 Mar 2026	398 days	398 days	1	None	1–3 business days
15 Mar 2026 — 14 Mar 2027	200 days	200 days	2	None	2–6 business days
15 Mar 2027 — 14 Mar 2029	100 days	100 days	4	None	4–12 business days
From 15 Mar 2029	47 days	10 days	about eight reissues a year	None	8–24 business days

The AHosting Certificate Reissuance Arithmetic. Validity and reuse periods are quoted from Baseline Requirements sections 6.3.2 and 4.2.1; the vetting duration is the figure AHosting publishes for EV issuance on its own product page. Effort columns are arithmetic, not estimates.

Notably, the DV column never changes. Automation is indifferent to frequency, which is exactly why the schedule was written the way it was. For an agency carrying certificates across dozens of client domains on reseller plans, that indifference is the difference between a background process and a recurring calendar obligation nobody owns.

When an OV SSL Certificate Is Genuinely the Right Call

An argument that ends in “never” is not an honest argument. There are real cases, and they share a shape: something other than a browser reads the organization name. In practice that means a regulator, an auditor, or a counterparty with a contract.

eIDAS, QWACs, and the One Place Identity Is Legally Required

In the European Union, identity inside a certificate is not decorative. The European Commission’s guidance on trust services explains that a qualified website authentication certificate “makes it possible to authenticate a website and to link the website to the identity of the person to whom the certificate is issued”. The same guidance states that the Regulation obliges web browsers to accept a QWAC and to display the identity data of the website owner in a user-friendly manner. That is the one context where the identity assertion is guaranteed a reader. However, the same guidance is explicit that use of such certificates “should be voluntary”, so this is a real exception rather than a requirement on ordinary sites.

Procurement Checklists, and How to Answer One Without Overbuying

The commonest genuine trigger is a contract. Enterprise security questionnaires, acquiring banks and public-sector frameworks still name validation tiers, and a supplier who argues with the clause loses the deal rather than the argument. Similarly, a store taking card payments may find its processor asking, even though no card scheme rule turns on the tier. Buy exactly what the clause names. Do not let an OV requirement become an EV purchase on a security argument the standards do not support, and read our note on where checkout trust is actually won or lost before attributing conversion problems to a certificate.

When the answer is genuinely OV or EV, the certificate stops being a plan feature and becomes a purchase, and the validation is the part you are buying. Accordingly it is worth buying from somewhere that will do the vetting alongside you rather than emailing a form: our SSL certificate options start at $9.99 for the coverage cases and run through to EV for the contractual ones.

What Our Support Queue Says About OV SSL and Certificate Types

Search data reveals what people ask a search engine. A support queue reveals what actually goes wrong afterwards, and the two rarely agree. Over the last twelve months our three brands logged 341, 447 and 254 technical tickets respectively, of which 76 concerned SSL and certificates — 11 at AHosting, 42 at ASEOHosting and 23 at SEOHost.net.

Interestingly, the recurring subjects in that set are uniformly operational: SSL Renew, renew SSL, SSL Cert, SSL Certs, ssl problem, Weird SSL. Not one of the recurring subjects concerns which validation tier to buy. The tier is a decision made once, usually at purchase, and then never revisited. Renewal is the thing that breaks, repeatedly, for years.

That is worth stating plainly because it inverts the sales conversation. The problem customers actually bring us is the problem automation solves and manual vetting worsens. For the mechanics of why renewals fail in the first place, which is almost always a DNS question rather than a certificate one, our post on server-level protection and what it does not cover sets out where certificate handling sits relative to everything else on a host.

Which Certificate Type Does Your Site Actually Need?

Rather than reasoning from a comparison table, answer four questions about the site you actually run. Above all, note that three of the four have nothing to do with security — which is itself the finding.

OV SSL Decision Checker

Four questions. Nothing is sent anywhere; the verdict is calculated in your browser.

1. Does a contract, acquiring bank, or procurement questionnaire name the validation tier in writing?

2. Do you serve EU users under a rule that requires a qualified website authentication certificate?

3. Do you need one certificate covering a wildcard or several unrelated domain names?

4. Can somebody complete a vetting call on demand, twice a year, every year?

Answer all four to see your result.

A Practical Checklist Before You Buy an OV SSL Certificate

Take this to any certificate reseller, including this one. Each item has a factual answer, and a vague response to any of them is itself the answer:

Which Reserved Certificate Policy Identifier will the issued certificate assert, and can you confirm it before I pay?
What is the maximum validity period I will actually receive, given the current 200-day ceiling?
How many separate vetting passes will that require from my staff over the next three years?
Is the organization name you will verify the one on my incorporation documents, or the one on my invoice?
If my requirement is wildcard or multi-domain coverage, can I buy that scope at the DV tier?
Which named contract, regulation, or scheme rule requires the tier you are recommending?
What happens to my certificate if a vetting call cannot be completed inside the reissuance window?

Finally, a note on migration that catches people out. Certificate vetting does not travel with a site, so a move to a new provider means reissuing, and an organization-validated certificate means re-vetting on somebody else’s schedule. That is worth planning for before the move rather than during it — see our guide to moving a site with zero downtime.

Frequently Asked Questions About OV SSL Certificates

DV vs OV SSL in 2026: which one does an ordinary business site need?

Typically, an ordinary business site needs DV and nothing more. Both certificate types encrypt the connection identically, and the CA/Browser Forum states in its own certificate profile section that every subscriber certificate type provides the same level of assurance of the device identity. What OV adds is a verified organization name inside the certificate, which no mainstream browser has surfaced in its address bar since 2019. The decision table in this post sets out the four cases where that name still earns its cost.

What does an OV SSL certificate prove that a DV certificate does not?

Specifically, an OV SSL certificate carries a verified legal entity in its subject field, where a DV certificate is forbidden from carrying one at all. The Baseline Requirements permit only a country code and a deprecated common name in a DV subject, and require that any other attribute must not be present. Both certificates prove exactly the same thing about the domain, because both are validated by the same domain control methods under the same section of the same rulebook.

Does AHosting include a free alternative to an OV SSL certificate in 2026?

Indeed, every AHosting hosting plan includes a free domain-validated certificate issued and renewed automatically through cPanel AutoSSL, which uses Let’s Encrypt as its default provider. That covers the encryption and the domain assurance in full. It does not carry an organization name, because Let’s Encrypt does not issue organization-validated certificates at all, and the reason it gives is the reason this post exists.

EV vs OV SSL: is extended validation worth the extra vetting time?

In practice, extended validation is now harder to justify than it was a year ago. Ballot SC102 passed in July 2026 and replaced the EV Guidelines’ own validity period and domain data reuse period with plain references to the Baseline Requirements, so EV no longer has separate rules for the domain half of the job. What remains distinct is the organizational vetting, which our own product page quotes at one to three business days per issuance.

When does a WooCommerce store processing card payments actually need an OV SSL certificate?

Notably, almost never on the strength of the payments alone. Card processing requirements are satisfied by a validly issued certificate and a correctly configured server, not by a particular validation tier, and no browser shows a checkout visitor the difference. The genuine triggers are contractual rather than technical: an acquiring bank, an enterprise customer, or a procurement questionnaire that names the tier explicitly.

How can I check which validation type my certificate actually has?

Fortunately, this is machine-checkable rather than a matter of trust. Every publicly trusted certificate asserts a Reserved Certificate Policy Identifier that names its type, and the four values are fixed by the Baseline Requirements. Open the certificate in your browser, find the certificate policies extension, and read the identifier. The table in this post maps each of the four values to the type it declares.

How often will a certificate need reissuing under the 2026 validity rules?

In practice, at least twice a year. The maximum validity period for any subscriber certificate fell to 200 days on 15 March 2026, drops to 100 days on 15 March 2027, and reaches 47 days on 15 March 2029. Those limits apply to every validation tier equally, so a certificate that requires manual vetting to reissue requires that vetting on the same shrinking schedule as a free one that renews itself.

Why does AHosting recommend against an OV SSL certificate for most hosting customers?

Ultimately, because the tier that costs more is the tier that cannot be automated, and the calendar is moving against manual issuance. Let’s Encrypt states that it does not offer organization or extended validation primarily because issuance for those types cannot be automated. Set that against a validity period falling from 200 days to 47, and the premium purchase becomes the one that generates recurring work for an assurance the browser does not display.

Is an OV certificate more secure than a DV certificate?

However tempting the assumption, no. The cryptography, the key sizes, the signature algorithms and the domain validation methods are identical, and the standards body that governs every public certificate authority says so directly in the section that defines the certificate profiles. The difference is what the certificate asserts about the organization behind the domain, and that assertion is read by auditors and procurement teams rather than by browsers.

Does AHosting charge extra for the certificate types most sites actually need?

Accordingly, no. The domain-validated certificate that covers the overwhelming majority of sites is included on every plan at no cost and renews without anyone touching it. Paid certificates start from $9.99 and exist for the cases this post identifies as genuine, which are wildcard and multi-domain coverage, and the contractual situations where a verified organization name is required rather than merely offered.

September 2, 2026

Your Server Is Running PHP Version X but WordPress Requires Y” – What to Actually Do

What the WordPress PHP Version Error Actually Is (And Why Your Whole Site Is Down)
- The exact line of WordPress that kills the request
- Why "check Site Health" is advice for a different problem
Which WordPress PHP Version Error Are You Looking At?
The Number in the WordPress PHP Version Error Is Not the Number You Want
- What WordPress requires versus what WordPress recommends
- Where each PHP branch stands right now
How to Fix the WordPress PHP Version Error in cPanel
- Change the version in MultiPHP Manager
- When the version changes and nothing happens – the AddHandler trap
What Breaks After You Raise PHP (And What Doesn't)
- The extension fatal almost nobody hits
- The memory limit that moved when you weren't looking
When You Cannot Change PHP – and What That Says About Your Host
A Practical Checklist: Before, During, and After the PHP Switch
Frequently Asked Questions About the WordPress PHP Version Error

TL;DR

The WordPress PHP version error is a pre-boot fatal, not an admin notice. Raise PHP in cPanel to clear it, but do not stop at the number in the message: WordPress enforces 7.4 and recommends 8.3 or greater.

The WordPress PHP version error is the one that gets pasted into Google verbatim, semicolons and all, because there is nothing else left to do with it. One line of text, no dashboard, no menu, no theme. If you searched the exact string and landed here, your site is returning an HTTP 500 and the fix takes about ninety seconds once you know which of four similar messages you are actually looking at.

Why the version in the message is the floor and not the target.

That last part is where most advice goes wrong. A WordPress PHP version error is not one message but four, and they mean different things, fire in different places, and need different responses. Worse, the version number printed in the message is not the version you should move to. This guide covers all of it, in the order an outage actually forces you to work.

What the WordPress PHP Version Error Actually Is (And Why Your Whole Site Is Down)

The WordPress PHP version error means the PHP interpreter on your server is older than the floor WordPress will start on, so WordPress refuses to boot at all. It is not a warning, not a notice, and not something you can dismiss. Every request to every URL on the site gets the same sentence and nothing else.

The exact line of WordPress that kills the request

A WordPress PHP version error comes from a function called wp_check_php_mysql_versions(), which lives in wp-includes/load.php and runs before almost anything else. It compares PHP_VERSION against a value WordPress sets in wp-includes/version.php. If PHP is older, WordPress sends a 500 Internal Server Error header, prints the sentence, and calls exit. Nothing after that point in the boot sequence ever runs, which is why the page has no styling, no header, and no way back in.

That detail matters more than it sounds. Because the failure happens before plugins, themes, and the admin area are loaded, none of the usual recovery routes exist. You cannot deactivate a plugin, you cannot switch themes, and you cannot reach wp-admin. The only surfaces still available are your hosting control panel, SFTP, and the file system.

Why “check Site Health” is advice for a different problem

Search results for this error are full of instructions that begin inside the WordPress dashboard. Open Tools, then Site Health, then read the PHP recommendation. That advice is written for the version notice WordPress shows when the site is working, not for the fatal that fires when it is not. If you can reach Site Health, you are not seeing the pre-boot error, and you have more time than this guide assumes.

Holding that distinction is worth the effort, because it is also the difference between an urgent fix and a scheduled one. A live site that is down is an emergency you resolve in the panel. A dashboard notice is a maintenance task you can plan around a backup and a staging test. Our white screen of death recovery guide covers the adjacent case where WordPress boots and then fails silently.

Which WordPress PHP Version Error Are You Looking At?

Four distinct strings in WordPress mention PHP versions, and they are routinely treated as one problem. They are not. The table below is the WordPress PHP Error Map: it names each message, the file it is emitted from, when it fires, and whether your site is currently serving traffic. Read your message against it before you change anything.

The WordPress PHP Error Map – four messages, four meanings. Verified against WordPress 7.1 source.

The message you are seeing	Emitted from	When it fires	Is the site up?
Your server is running PHP version X but WordPress Y requires at least Z.	wp-includes/load.php	Every request, before WordPress boots	No – HTTP 500 on every URL
WordPress X requires the json PHP extension.	wp-includes/load.php	Every request, before WordPress boots	No – HTTP 500 on every URL
You cannot update because WordPress X requires PHP version Y or higher and MySQL version Z or higher.	wp-admin/update-core.php, upgrade.php, install.php	Inside wp-admin, when you try to update or install	Yes – only the update is blocked
The update cannot be installed because WordPress X requires PHP version Y or higher and MySQL version Z or higher.	wp-admin/includes/update-core.php	During an update that has already started	Yes – the update aborts, the old version keeps running

If your message is one of the bottom two, close this section and breathe. Your site is serving visitors normally and you are looking at a blocked upgrade, which is a different job with a different urgency. Those bottom two rows also name MySQL alongside PHP, and the database half is the one people miss: WordPress checks both in the same place, so a message that mentions PHP may be failing on the other requirement.

The Number in the WordPress PHP Version Error Is Not the Number You Want

Here is the part almost nobody says out loud. The version a WordPress PHP version error prints is the absolute floor it will start on, and that floor is a version that stopped receiving security fixes years ago. Clearing the error by moving to exactly that number ends your outage and leaves you running unsupported PHP, which is a different problem you have now agreed to have.

What WordPress requires versus what WordPress recommends

WordPress 7.1 sets its minimum to PHP 7.4. That is the number in the error. On its server requirements page, WordPress recommends PHP 8.3 or greater, alongside MariaDB 10.11 or MySQL 8.0, and states plainly that while WordPress will still run on the older baseline, those versions have reached end of life and may expose your site to security vulnerabilities. Two numbers, two purposes: one keeps the software from starting, the other keeps it defensible.

So the target of a WordPress PHP version error fix is not the number in the message. Aim for the recommendation and land above both. If you want the reasoning behind picking a specific modern branch rather than the newest available, our guide to choosing a PHP version in cPanel works through the tradeoff in detail.

Where each PHP branch stands right now

PHP publishes a fixed support calendar: two years of active support, then a third year of security-only fixes, then nothing. The table below is that calendar as it stands today, taken from the PHP project support schedule. Anything not listed on that page, including PHP 8.1 and everything below it, receives no fixes from the project at all.

PHP branch support status, September 2026. Source: the PHP project support schedule.

PHP branch	Active support until	Security support until	What that means for a WordPress site today
8.1 and older	Ended	Ended	No project fixes at all. Move off it.
8.2	2024-12-31	2026-12-31	Security fixes only, and they stop this December.
8.3	2025-12-31	2027-12-31	Security fixes only. Clears the WordPress recommendation.
8.4	2026-12-31	2028-12-31	Actively supported. The sensible default today.
8.5	2027-12-31	2029-12-31	Newest branch. Fine once plugins confirm support.

A quick way to keep this straight later is the PHP end-of-life calendar, which renders the same dates as a timeline. Note the shape of the trap: 8.2 is still described as supported in a lot of writing, and its security window closes in December. Choosing a branch that is merely alive today buys you very little.

How to Fix the WordPress PHP Version Error in cPanel

With the target version settled, clearing a WordPress PHP version error is short work. On any cPanel host, including every AHosting shared plan, the PHP version is set per domain rather than per account, so you can move one site without touching the others. Take a backup first if the account has one available, then work through the two steps below in order.

Change the version in MultiPHP Manager

Log in to cPanel and open MultiPHP Manager under the Software section. You will see a list of every domain and subdomain on the account with its current PHP version beside it. Select the checkbox for the affected domain, choose 8.4 from the PHP Version dropdown, and apply. The change takes effect on the next request, so reload the site immediately and check whether the message is gone.

One setting to avoid here is inherit, which tells the domain to follow the server default. Inherit is convenient until the server default moves underneath you, and it also prevents you from enabling PHP-FPM on that domain. Choose an explicit version so the domain keeps the version you picked regardless of what changes at the server level later.

When the version changes and nothing happens – the AddHandler trap

If MultiPHP Manager reports the new version and the site still returns the same WordPress PHP version error, the panel is not being obeyed. The usual cause is an AddHandler line in the .htaccess file at your document root that names a specific old PHP handler. Directory-level Apache configuration takes precedence over the panel setting, so the panel is telling you one thing while the web server does another.

Open .htaccess over SFTP or the cPanel File Manager and look for a line naming a handler such as ea-php74 or ea-php56. Comment it out with a hash at the start of the line, save, and reload. This is worth checking before anything else, because it explains the majority of cases where a correct version change appears to do nothing at all, and it is invisible from inside WordPress.

What Breaks After You Raise PHP (And What Doesn’t)

Your site is back. Now comes the part the outage hid from view, because raising a PHP version changes the runtime underneath every plugin and theme on the site. Two things are commonly feared here, one of which is almost never the problem, and one genuine change that is easy to miss because nothing announces it.

The extension fatal almost nobody hits

WordPress core requires exactly two PHP extensions to boot: json and hash. Both have been compiled into PHP by default for years, so the missing extension fatal listed in the error map above is rare in practice. If somebody tells you that switching handlers will strip the extensions WordPress needs, they are describing plugin requirements rather than core ones.

The real post-switch failures come from plugin and theme code that has not kept up with the language. Jumping from PHP 8.1 to 8.2 or later, for example, triggers the deprecation described in the PHP RFC on dynamic properties, which raises a warning for every undeclared property an older plugin sets. It still works, but it fills logs, and the same code becomes a hard error in PHP 9. The rest of the 8.2 changes are documented in the PHP 8.2 deprecation notes.

The memory limit that moved when you weren’t looking

This is the change nothing tells you about. On a cPanel host, PHP memory_limit is a property of the handler, not of the site, so selecting a different PHP version can hand you a different per-request memory ceiling. On AHosting shared plans the three handlers we run are not configured identically, and the spread is wide enough to turn a working site into an intermittently failing one.

The AHosting PHP Handler Memory Map – per-request memory_limit by handler on AHosting shared plans.

Handler	PHP memory_limit	Community support status	What changes if you move here
ea-php84	256 MB	Active support until 2026-12-31	Current default. Halves the ceiling coming from ea-php83.
ea-php83	512 MB	Security fixes until 2027-12-31	The highest ceiling of the three handlers.
ea-php81	128 MB	End of life since 2025-12-31	The lowest ceiling, on an unsupported branch.

Read that table in the direction you are actually moving. A site moving from ea-php83 to ea-php84 gains a supported branch and loses half its memory ceiling in the same click, which surfaces later as an exhausted memory error on a heavy admin page rather than as anything connected to the version change. Check phpinfo once the switch is done, and see our guide to WordPress memory limit errors for why raising the value in wp-config often achieves nothing.

One more distinction worth keeping. The PHP memory_limit is not the same thing as the container memory cap your plan enforces, and raising the first above the second buys you nothing at all. If your errors after a handler change look like resource exhaustion rather than a version problem, our diagnostic tree for 500, 503, and resource limit errors separates the three.

Check Your PHP Version Against WordPress

Pick the PHP version your server reports. This tells you whether WordPress will boot, whether the branch is still patched, and what to do next.

Your current PHP version

Select a version to see where you stand.

See which PHP versions our hosting plans run

When You Cannot Change PHP – and What That Says About Your Host

Sometimes MultiPHP Manager is not there, or the versions offered stop below what WordPress recommends, or the setting is locked to the server default. That is a real constraint and worth naming honestly, because at that point the version problem has stopped being a WordPress problem and become a hosting one.

There are two legitimate ways out. If the blocker is application code rather than the panel, commercial long-term support for end-of-life PHP branches exists and covers 7.2 through 8.1, which buys time to rewrite rather than permission to stop. If the blocker is the platform, the answer is a platform where the choice is yours to make.

For context on what that looks like: our shared platform runs CloudLinux 9 and LiteSpeed with ea-php80 through ea-php85 selectable per domain from MultiPHP Manager, and older branches available for legacy applications that genuinely need them. If deciding between handlers is not work you want to own at all, that is exactly the decision our managed WordPress hosting plans make for you, and the root account is yours to hold on a VPS if you would rather own the handler yourself. The tuning above is the part we take off your hands.

Whichever route you take, moving hosts to escape a PHP ceiling is a planned job rather than an emergency one. Our WordPress hosting requirements guide lists what to check before you commit, and a WordPress PHP version error is a poor reason to rush that decision.

A Practical Checklist: Before, During, and After the PHP Switch

Work through this in order. Sequence matters here because two of the steps are things people only discover they skipped once the site is already back up and quietly misbehaving.

Read the exact message against the error map above and confirm whether your site is actually down or merely blocked from updating.
Take a backup, or confirm one exists from within the last day, before touching the handler.
Set the target version to 8.4 in MultiPHP Manager, per domain, and avoid the inherit setting.
Reload the site immediately. If the message survives, open .htaccess and remove any AddHandler line naming an old handler.
Check phpinfo and confirm both the running version and the memory_limit, which may have changed with the handler.
Load a few heavy pages, including the admin dashboard and one editor screen, rather than only the homepage.
Check the error log for new deprecation warnings from plugins and themes, and update anything that is producing them.
If a plugin fatals on the new branch, roll the handler back to the previous version, then fix the plugin rather than living on the old runtime.

The last item is the one worth arguing about. Rolling back is a legitimate move under time pressure, but it is a pause and not a resolution, because the branch you rolled back to is the one that stops receiving fixes. Set a date to come back to it while the details are still fresh.

Frequently Asked Questions About the WordPress PHP Version Error

How do I fix the WordPress PHP version error on shared hosting in 2026?

Specifically, open cPanel, go to MultiPHP Manager, select the affected domain, and set the PHP version to 8.3 or 8.4. The site returns as soon as the handler changes. If the message survives the change, an AddHandler line in .htaccess is overriding the panel, and that line has to be removed before anything else will work.

WordPress PHP version error vs the white screen of death: what is the difference?

In contrast to a white screen, the WordPress PHP version error prints an actual sentence. That difference tells you where the failure happened. The version error is thrown by wp-includes/load.php before WordPress boots, so nothing else has run yet. A white screen means WordPress booted and then something later, usually a plugin or theme, fataled with display_errors off.

PHP 8.3 vs PHP 8.4 for WordPress in 2026: which version should I choose?

Typically, choose 8.4. Both clear WordPress recommended baseline of 8.3, but 8.3 left active support on 2025-12-31 and now receives security fixes only, while 8.4 stays in active support until 2026-12-31 and is patched for security until 2028-12-31. Pick 8.3 only when a plugin you cannot replace is not yet 8.4 compatible.

Does the WordPress PHP version error affect AHosting customers running ea-php81 on shared plans?

Notably, no. PHP 8.1 is far above the 7.4 floor WordPress enforces, so the error never fires on ea-php81. The reason to leave that handler is different: PHP 8.1 fell out of community security support on 2025-12-31, and on AHosting shared plans ea-php81 also carries a 128 MB memory_limit, the lowest of the three handlers we run.

Why does WordPress still show the old PHP version after I changed it in cPanel?

In practice, an AddHandler directive in your .htaccess is pinning the old handler for that directory, and directory-level configuration wins over the panel setting. Open the .htaccess in the document root, comment out or delete the AddHandler line naming the old version, and reload. This is the single most common reason a correct MultiPHP Manager change appears to do nothing.

Which PHP extensions does WordPress 7.1 actually require in order to boot?

Specifically, two: json and hash. Both are compiled into PHP by default on every modern build, which is why the missing extension fatal is rare in practice. Everything else people describe as required, including mysqli, curl, gd, and mbstring, is required by plugins, themes, or particular features rather than by the core boot sequence.

What is the recommended PHP version for WordPress, and is it the same as the minimum?

In fact they are different numbers, and confusing them is the whole trap. WordPress enforces a minimum of PHP 7.4, which is the number printed in the error. WordPress separately recommends PHP 8.3 or greater on its requirements page. Satisfying the minimum clears the outage; only the recommendation leaves you on PHP that is still receiving fixes.

Can I clear the WordPress PHP version error without losing my AHosting memory limit?

Ultimately yes, but check the number afterward rather than assuming it carried over. On AHosting shared plans the per-request memory_limit travels with the handler: ea-php84 ships 256 MB, ea-php83 ships 512 MB, and ea-php81 ships 128 MB. Moving between handlers changes that ceiling silently, so read phpinfo once the switch is done.

How does AHosting help resolve a WordPress PHP version error in 2026 without downtime?

Fortunately, the handler change itself is instantaneous, so the fix is measured in seconds rather than a migration window. Our shared platform runs CloudLinux 9 and LiteSpeed with ea-php80 through ea-php85 selectable per domain, and support will read the .htaccess for a conflicting AddHandler line before you do. The checklist above is the same order we work in.

What does the WordPress PHP version error mean when MySQL is named in the message?

Accordingly, you are looking at the update-time message, not the pre-boot fatal, and your site is still running. The wp-admin variants name both requirements together because WordPress checks PHP and the database in one place before allowing an update. Your site is up; what is blocked is the version jump, and the database half may be the real reason.

September 1, 2026

Slow FFmpeg Encoding on Shared Hosting: Find Your CPU Cap

Why Slow FFmpeg Encoding Is Almost Never the Command
- The two numbers that decide every encode
What Causes Slow FFmpeg Encoding Inside a Shared Container
The Shared Hosting Encode Ceiling
Measure It Yourself: The Three-Number Slow FFmpeg Encoding Diagnostic
If Slow FFmpeg Encoding Is Throttling, Tuning Buys Less Than You Think
- What the preset flag actually moves
- What the threads flag cannot move
When Shared Hosting Is the Wrong Machine for the Job
What Dedicated CPU Changes
A Practical Checklist: Is Your Hosting FFmpeg-Ready?
Frequently Asked Questions About Slow FFmpeg Encoding

TL;DR

Slow FFmpeg encoding on shared hosting is usually a CPU cap, not a bad command. Time one encode, divide user seconds by your plan’s cores, and you have the floor no flag can beat.

An encode that used to take twenty minutes is still running after two hours, and every guide you find tells you to change a flag. Before you change anything, it is worth knowing that slow FFmpeg encoding on a shared plan is far more often a property of the container than of the command. The encoder is not misconfigured. It is being handed less CPU time than it asked for, and it has no way to tell you so.

Listen: why an over-running encode on shared hosting is usually a CPU speed cap rather than a wrong flag. By Matt Chrust, Director of Business Development, AHosting.

This post is the measurement that comes first. It shows what a shared container actually gives FFmpeg when slow FFmpeg encoding is the symptom, how to read your own numbers in one timed run, and how to work out the floor below which no flag can take you. If the measurement says your command is the problem, our FFmpeg performance optimization tips cover the tuning in detail. If it says the container is the problem, tuning was never going to help. For the wider picture on what a media host needs, see our complete guide to FFmpeg hosting for video creators.

Why Slow FFmpeg Encoding Is Almost Never the Command

Consequently, the most useful thing you can do first is stop trying flags. Encoding is one of the few workloads that will consume every scrap of CPU it is offered, indefinitely, without ever raising an error. That property is what makes it so easy to misdiagnose: a database query that runs out of resources fails loudly, while an encode that runs out of resources simply takes longer.

Notably, the encoder cannot distinguish the two states either. FFmpeg asks the operating system to run its threads and the operating system obliges, just more slowly than the thread count implies. Nothing in the progress output says so. The frames-per-second figure drops and keeps dropping, which reads exactly like a hard encoding preset even when the preset is fine. That ambiguity is why slow FFmpeg encoding gets misattributed to the command so consistently.

The two numbers that decide every encode

Specifically, only two quantities matter, and neither is a flag. The first is the total CPU time the encode requires, measured in CPU seconds. That is a property of the source file, the codec and the settings, and it is the number a preset change actually moves. The second is the rate at which your container is permitted to spend CPU time. That is a property of your hosting plan, and no command you type will move it at all.

Together those two numbers give the answer directly. Divide the CPU seconds by the effective cores your plan allows, and you have the shortest wall-clock time the encode can possibly take. Everything else in this post is either how to measure those two numbers or what to do once you have them, because slow FFmpeg encoding is entirely determined by that pair.

What Causes Slow FFmpeg Encoding Inside a Shared Container

Fundamentally, a shared hosting account is not a small server. It is a fenced region of a large one, and the fence is enforced by limits your account never sees. Three of them touch encoding, and they behave in two completely different ways: one slows work down, and the others stop it outright.

CPU speed is a time budget, not a core count

Notably, the limit that governs encoding is expressed as a percentage rather than a number of cores. CloudLinux, which enforces the limits on most cPanel shared platforms, defines it as a “CPU speed limit, relative to a single core” and gives the conversion plainly: CloudLinux documents that “100% would mean 1 core, 150% would mean 1.5 cores.” Your plan does not own two processors. It owns the right to spend two seconds of CPU time per second of wall time.

Consequently, exceeding that rate does not produce an error. The kernel simply stops scheduling your threads until the next accounting period begins. Documentation for Linux CFS bandwidth control states the mechanism precisely: “Once all quota has been assigned any additional requests for quota will result in those threads being throttled.” Throttled, not refused. The work still happens, and it happens at whatever pace the quota permits.

In practice, that single design decision explains the entire symptom. There is no failure to find in a log, because nothing failed. CloudLinux even notes the side effect that gives the game away, warning that low speed limits cause “CPU context switching which leads to increased %sys” — a number you can read yourself in a moment.

Why FFmpeg counts cores you are not allowed to use

Furthermore, FFmpeg does not know about any of this, and its defaults actively work against you. The FFmpeg codec documentation states that the threads option will “Set the number of threads to be used, in case the selected codec implementation supports multi-threading,” with a “Default value is ‘auto’.” Automatic sounds safe. The question is automatic with respect to what.

Specifically, it is automatic with respect to the machine, not your allowance. The FFmpeg command-line documentation is explicit for the filter pipeline: the default thread count “is the number of available CPUs.” On a shared server that is the physical host, which may hold dozens of cores belonging almost entirely to other people. FFmpeg cheerfully starts a thread for each one.

Moreover, the tools you would use to check this mislead in the same direction. The nproc manual page promises “the number of processing units available to the current process, which may be less than the number of online processors,” and its all option prints installed processors “disregarding any OpenMP environment variables, or CPU quotas.” A speed cap is not a restriction on which processors you may touch; it is a cap on how much time you may spend across all of them. So the count looks generous and the budget is not.

The limits that stop an encode instead of slowing it

By contrast, the other two limits fail loudly, which makes them easier to recognize. When the entry process limit is reached, CloudLinux notes that the server “will return error code 508” — the subject of our guide to what entry process limits really mean. When the process limit is reached, no new process can start at all, and the platform returns a 500 or 503 instead.

Therefore, a useful rule of thumb: if your encode errors, look at entry processes, process count or memory. If your encode finishes correctly but late, look at CPU speed. These are different limits with different symptoms, and confusing them sends you tuning the wrong thing entirely. The distinction matters when you compare shared hosting plans, because the published feature list rarely separates them.

The Shared Hosting Encode Ceiling

Accordingly, here is the arithmetic in full, using the CPU speed allocations on AHosting shared plans. These figures were pulled directly from the platform on 31 August 2026 and are not published on any plan page, ours included, which is precisely why anyone diagnosing slow FFmpeg encoding is so rarely handed the one calculation that settles it.

Plan	CPU speed limit	Effective cores	Floor for a 600-CPU-second encode	Floor for a 3,600-CPU-second encode
Bronze	100%	1.0	10m 0s	1h 0m
Silver	200%	2.0	5m 0s	30m 0s
WooStart	300%	3.0	3m 20s	20m 0s
Gold	400%	4.0	2m 30s	15m 0s
FFStart VPS	4 dedicated vCPU	4.0	2m 30s	15m 0s
FFPower VPS	8 dedicated vCPU	8.0	1m 15s	7m 30s

The Shared Hosting Encode Ceiling — minimum wall-clock time by plan, derived as measured CPU seconds divided by effective cores. AHosting CPU allocations verified 31 August 2026. Assumptions: the encode parallelizes perfectly across the allowance, no storage wait, no contention from neighboring accounts. Real encodes are slower than the floor and never faster.

Ultimately, two readings of that table matter more than the numbers themselves. The first is that Gold and FFStart share a floor of four cores, so the arithmetic alone does not separate them — what separates them is that a shared container only reaches its cap while its neighbors are idle, whereas dedicated vCPU are always there. The second is that the floor scales with nothing you type. A preset change alters the left-hand input; the plan alters the divisor.

Measure It Yourself: The Three-Number Slow FFmpeg Encoding Diagnostic

Fortunately, you do not have to take any of this on trust, and you do not need server access to check it. One command produces three numbers, and those three numbers distinguish a throttled container from a disk bottleneck from a genuinely single-threaded encode. Those three causes of slow FFmpeg encoding call for completely different responses, and guessing between them wastes the most time.

First step: time a single encode

Specifically, run the encode you already run, with the word time in front of it. The time manual page describes what you get: when the command finishes, time “writes a message to standard error giving timing statistics about this program run.” Use a representative source file rather than a short clip, because startup costs distort anything under about a minute.

Notably, you want the run to be otherwise ordinary. Do not lower the preset for the test and do not run two encodes at once. The point is to characterize the workload you actually have, not a tuned version of it.

Second step: read real against user against sys

Specifically, real is “the elapsed real time between invocation and termination” — the wall clock. User is CPU time your code spent in user mode, and sys is CPU time spent in the kernel on your behalf. The important thing is that user and sys are sums across every thread, so on a genuinely parallel machine they can far exceed real.

Therefore, the ratio is the signal. Divide user by real and you have your effective parallelism: how many cores the encode actually managed to use, averaged over the run. A four-core machine doing four-core work reports close to 4.0. A container capped at one core reports close to 1.0 no matter how many threads FFmpeg started, which is the fingerprint of throttling.

Third step: work out your effective parallelism

Consequently, three comparisons resolve almost every case. Read them against your own numbers rather than against a benchmark, because the absolute values depend entirely on your source material.

What you observe	Effective parallelism (user divided by real)	What it means	What to do
user is far below real, sys is small	Well under 1.0	The process is waiting, not computing. Storage or network is the bottleneck.	Stop tuning the encoder. Check where the source and destination files live.
user is close to real, and stays there however many threads you set	Close to 1.0	You are capped near one core. This is CPU throttling.	A preset change helps proportionally. A thread change does not help at all.
sys is an unusually large share of total CPU time	Any value	Context switching overhead, the documented side effect of a low speed limit.	Reduce the thread count toward your effective cores rather than raising it.
user is a clean multiple of real, near your plan’s core figure	Close to your allowance	You are using everything the plan permits. Nothing is broken.	You are at the ceiling. Only more CPU or less work changes the outcome.

The Three-Number Diagnostic — interpreting real, user and sys from a single timed FFmpeg run. Effective parallelism is user divided by real.

If Slow FFmpeg Encoding Is Throttling, Tuning Buys Less Than You Think

That said, tuning is not useless, and the diagnostic tells you exactly how much it is worth. The two families of change behave very differently once a cap is in play, and knowing which is which saves a great deal of time.

What the preset flag actually moves

In practice, the preset is the one lever that reliably works under a cap, because it reduces the left-hand side of the division. A faster preset asks the encoder to search fewer options per frame, which costs fewer CPU seconds and therefore lowers the floor itself. You pay for it in file size at the same visual quality, which may or may not matter for your delivery.

Similarly, cutting before encoding, scaling down before encoding rather than after, and avoiding a re-encode altogether with a stream copy all reduce the CPU cost rather than the rate. Our guide to FFmpeg presets, CRF and stream copying covers each of those in command-level detail, and it is the right next stop once the diagnostic points at the workload rather than the container.

What the threads flag cannot move

By contrast, thread count changes nothing about the total CPU seconds required and therefore nothing about the floor. Raising it on a capped container divides the same budget among more workers, which adds scheduling overhead for no gain — the increased system time CloudLinux warns about. Lowering it toward your effective core count sometimes recovers a few percent, which is worth doing and is not a fix.

Furthermore, this pattern will be familiar to anyone who has tried to solve a resource problem by raising a number in a configuration file. It is the same shape as the reason raising the WordPress memory limit does not work on shared hosting: a setting inside the container cannot grant something the container itself is denied. The number goes up and the ceiling does not move.

When Shared Hosting Is the Wrong Machine for the Job

Ultimately, some workloads do not belong on a shared plan at all, and the honest answer is to say so rather than to keep tuning. Where slow FFmpeg encoding is structural, tuning never reaches it. Three tests settle that question, and each one uses numbers you now have.

First and foremost, the deadline test. Take your measured CPU seconds, divide by your plan’s effective cores, and compare the result with the window you actually have. When a nightly batch needs six hours of floor inside a four-hour window, no flag closes that gap — the arithmetic has already ruled it out.

Secondly, the ladder test. An adaptive HLS or DASH ladder encodes the same source once per rung, so a five-rung ladder costs roughly five times a single encode. Multiply before you plan, because ladders are where shared plans stop being merely slow and start missing publishing schedules altogether. This is the usual trigger for moving to a VPS with guaranteed resources.

Thirdly, the sustained-load test. A shared container reaches its cap only while its neighbors leave it free, which is tolerable for an occasional encode and unreliable for continuous work. Where encoding runs most of the day, the right machine is a server whose CPU nobody else can claim. If you are weighing the step up more generally, our comparison of shared hosting against VPS hosting for growing sites sets out what changes and what does not.

What Dedicated CPU Changes

Accordingly, the value of moving is narrower and more specific than most upgrade advice suggests. Dedicated CPU does not make FFmpeg faster. It removes the divisor problem: the cores are yours for the whole run, so the floor you calculate is the floor you get, every time, rather than the floor you get when the server is quiet.

Specifically, AHosting FFStart provides 4 vCPU, 8 GB of RAM, 75 GB of SSD storage and 6 TB of traffic, while FFPower doubles the processor and memory allocation to 8 vCPU and 16 GB. Both ship FFmpeg with codecs and a segmenter already installed on Ubuntu 24.04.3 LTS, with CloudPanel and SSH access, covering libx264, libx265, VP9 and AV1 alongside HLS and MPEG-DASH output. The encoding described in this post needs guaranteed CPU rather than a share of somebody else’s, and that is what the FFmpeg hosting plans allocate.

Notably, none of that is a reason to move if your diagnostic came back clean. A container running at its full allowance on an occasional encode is working exactly as intended, and the money is better spent elsewhere. The calculator below is there to make the comparison concrete rather than persuasive.

Encode Ceiling Calculator

Run your encode once under time, take the user figure in seconds, and enter it here. The result is the shortest wall-clock time that encode can take on each tier. No command-line flag can go below it.

Measured CPU seconds (the user figure)

Arithmetic only, from published CPU allocations. It is a floor, not a prediction: real encodes also wait on storage, and a shared container reaches its cap only while its neighbors leave it free.

See the FFmpeg hosting plans

A Practical Checklist: Is Your Hosting FFmpeg-Ready?

Finally, run through this before you change anything. Each item is answerable from the numbers this post has produced, and the order matters — measuring after tuning tells you nothing.

One representative encode timed, with real, user and sys written down.
Effective parallelism calculated to one decimal place by dividing user by real.
Your plan’s CPU speed limit known as a percentage, rather than guessed from the processor count.
The floor computed from measured CPU seconds divided by effective cores, then compared against your deadline.
Symptom classified: does the encode error, or does it finish correctly but late?
Rungs counted in any adaptive ladder, with the CPU cost multiplied accordingly.
Source and destination files confirmed to sit on local storage rather than a network mount.
A faster preset tried, which lowers the CPU cost, before the thread count, which does not.
Workload characterized as occasional or continuous, since that is what decides shared against dedicated.

Ultimately, the discipline this post asks for is a single timed run before any tuning. Diagnosing slow FFmpeg encoding costs exactly one encode, and it tells you which half of the problem you are in, which is more than any amount of flag experimentation will do.

Frequently Asked Questions About Slow FFmpeg Encoding

Why is slow FFmpeg encoding almost never caused by the wrong command?

Typically, the command is the second thing to check rather than the first. A container capped on CPU speed spends the same total CPU seconds whichever flags you pass, so the real question is how quickly your plan lets FFmpeg spend them. Measure before you tune: the three-number diagnostic below separates a throttled container from a badly written command in a single run.

Why is my FFmpeg encode so slow on shared hosting?

Specifically, a shared plan gives your account a fixed share of a CPU core and FFmpeg cannot exceed it. Where that share is 100 percent of one core, an encode needing 600 seconds of CPU time cannot finish in under 600 seconds of wall time. Extra threads divide the same budget into smaller pieces rather than adding to it.

What CPU speed limit does an AHosting shared plan give FFmpeg in 2026?

Notably, AHosting shared plans allocate CloudLinux LVE CPU speed as Bronze 100 percent, Silver 200 percent, WooStart 300 percent and Gold 400 percent, where 100 percent equals one core. Those four figures were pulled from the platform on 31 August 2026. The ceiling table below converts each one into a minimum wall-clock time for any encode whose CPU cost you have measured.

CPU throttling vs disk I/O: which one is causing slow FFmpeg encoding?

Fortunately, one timed run answers this. When user time approaches real time multiplied by your effective core count, the encode is CPU bound and throttled. When real time is far larger than user and sys time added together, the process is waiting on storage instead, and no encoder flag will help. The decision table below maps each combination to its cause.

AHosting FFStart VPS vs a Gold shared plan for slow FFmpeg encoding in 2026: which finishes first?

In practice, FFStart finishes first in the general case even though both allow roughly four cores of CPU time. A Gold container reaches its 400 percent cap only while the neighbors sharing that server leave it free, whereas FFStart ships four dedicated vCPU that nobody else can claim. Sustained batch work is where that difference compounds.

How do real, user and sys times explain slow FFmpeg encoding?

Specifically, real is elapsed wall-clock time, user is CPU time spent running your code and sys is CPU time spent inside the kernel. Dividing user by real gives your effective parallelism. A machine genuinely using four cores reports close to 4.0; a container capped at one core reports close to 1.0 however many threads FFmpeg started.

What is the shared hosting encode ceiling and how do I calculate mine?

Ultimately, the ceiling is a single division: measured CPU seconds divided by your plan’s effective cores gives the shortest wall-clock time an encode can possibly take. Nothing in the command lowers that floor, because the container sets it rather than the encoder. The calculator below runs the arithmetic across every AHosting tier once you supply your own measured figure.

Does raising the threads flag fix slow FFmpeg encoding on a CPU-limited container?

Indeed, it usually makes matters marginally worse. FFmpeg defaults its thread count to auto, which resolves to the number of processors the machine reports rather than the number your plan permits. More threads against a fixed CPU budget means more context switching for the same total work, which is exactly why CloudLinux warns that low speed limits drive system time upward.

When should an HLS ladder suffering slow FFmpeg encoding move onto an FFmpeg VPS?

For example, a five-rung HLS ladder re-encodes one source five times, so its CPU cost is roughly five single encodes. Once that total exceeds what your plan can spend inside the window you actually have, the ladder belongs on dedicated CPU. The three tests below express that threshold in terms of your own measured numbers rather than a generic recommendation.

Which codecs and streaming formats does AHosting FFmpeg hosting ship in 2026?

Additionally, AHosting FFmpeg plans ship FFmpeg with codecs and a segmenter preinstalled on Ubuntu 24.04.3 LTS, covering H.264 through libx264, H.265 through libx265, VP9 and AV1. Both HLS with m3u8 manifests and MPEG-DASH with mpd manifests are supported. FFStart provides four dedicated vCPU and FFPower provides eight.

August 31, 2026

WooCommerce Black Friday Hosting: The 12-Week Countdown Site: AHosting.net

What WooCommerce Black Friday Hosting Has to Survive
- The Checkout Is the One Page That Cannot Be Cached
- Why Peak Concurrency Beats Monthly Visits as the Planning Unit
Your Checkout Ceiling: The One Number Peak Planning Turns On
The 12-Week WooCommerce Black Friday Hosting Countdown
How to Rehearse Peak Load Without Taking the Store Down
- Building a Checkout Load Test That Resembles Real Buyers
- The Four Signals to Watch During a WooCommerce Black Friday Hosting Rehearsal
When WooCommerce Black Friday Hosting Needs More Than a Shared Plan
- Shared, WooStart, VPS, Dedicated: A Peak-Load Comparison
What AHosting Publishes That Makes Peak Planning Possible
- Check Your WooCommerce Black Friday Hosting Readiness
The Change Freeze and the Rollback You Hope Not to Use
A Practical WooCommerce Black Friday Hosting Checklist
Frequently Asked Questions About WooCommerce Black Friday Hosting

TL;DR

WooCommerce Black Friday hosting is decided by one number: entry processes divided by checkout execution time. Measure it in September, rehearse it in October, freeze the site in November.

Most advice about WooCommerce Black Friday hosting arrives as the same four bullets: upgrade the plan, add a content delivery network, turn on caching, take a backup. None of it is wrong. All of it is unfalsifiable, because none of it produces a number you can check your store against.

Why peak-season capacity comes down to entry processes divided by checkout execution time, and the twelve-week schedule that turns that number into a plan.

There is such a number, and your host either publishes the inputs or it does not. This post derives it, shows what makes it collapse under load, and hangs a dated twelve-week schedule off it, with an explicit go or no-go gate at the end of each stage. Black Friday 2026 falls on November 27, so the clock starts the first week of September.

What WooCommerce Black Friday Hosting Has to Survive

Peak season does not raise the amount of work your server can do. It changes the kind of work it is asked to do, and the change runs in the wrong direction. Understanding that inversion is most of what WooCommerce Black Friday hosting planning consists of.

The Checkout Is the One Page That Cannot Be Cached

On an ordinary day, a well configured store serves nearly everything from cache. Product pages, category listings and the home page are rendered once and handed to every later visitor as static HTML, which is why a shared container can absorb traffic that looks alarming in an analytics chart. Cached pages consume zero entry processes.

Cart, checkout and account pages are different by necessity. Each visitor sees different contents, so each request has to execute PHP and query the database. Every serious caching layer excludes them deliberately, and the LiteSpeed Cache exclusion settings are where that exclusion is configured and confirmed. Getting the exclusion wrong in either direction is expensive: cache the checkout and customers see each other’s carts, leave a heavy page uncached and you burn slots for nothing. The verification method is in our guide to excluding checkout from cache correctly.

Consequently, a sale inverts the traffic mix. The share of requests that reach PHP climbs from a few percent to a large fraction, and the slowest pages in the store are the ones absorbing it.

Why Peak Concurrency Beats Monthly Visits as the Planning Unit

Monthly visits describe a year of browsing. They tell you nothing about the ninety seconds after an email lands in 40,000 inboxes, which is the only window that decides whether a sale goes well.

The unit that matters is concurrency: how many requests are being processed at the same instant. A container permits a fixed number of simultaneous PHP processes, and when they are all busy the next request waits in a queue rather than failing outright. Queued requests are what customers experience as a store that has gone slow, and beyond a certain queue depth they are what the server reports as a resource limit. We covered the underlying arithmetic for page traffic in our analysis of how many concurrent users shared hosting handles.

Checkout raises the stakes because each unit of work is slower and worth more. A queued product page costs you patience; a queued payment step costs you the order.

Your Checkout Ceiling: The One Number Peak Planning Turns On

Everything above reduces to a single quantity. Given a fixed number of concurrent PHP slots and a known time per checkout request, the throughput your store can sustain is fully determined. Nothing about sizing WooCommerce Black Friday hosting is proprietary or mysterious once those two inputs exist.

The Checkout Ceiling Formula

Divide the number of entry processes by the checkout execution time in seconds, and you have checkout requests per second. Multiply by sixty for the per-minute figure. The relationship is a direct application of the 1961 queuing result known as Little’s Law, which states that the average number of items in a system equals the arrival rate multiplied by the time each one spends there. Rearranged for a system with a hard concurrency cap, it gives you the maximum arrival rate the cap will sustain.

Two adjustments make the result honest. One checkout does not equal one request: a real order costs roughly half a dozen uncacheable calls between adding to cart, applying a coupon, refreshing totals, placing the order and returning from the payment gateway. And checkout is not the only thing competing for slots, since administrative sessions, scheduled jobs and crawlers draw from the same pool. Assume you get half of the theoretical figure and you will not be disappointed.

The WooCommerce Checkout Ceiling Table

Below is the arithmetic worked through at 40 entry processes, which is the figure the AHosting WooStart plan publishes. Read it as a model rather than as a measurement: it assumes six uncacheable requests per order and slots that are otherwise idle. Other plan tiers scale the first column linearly.

Checkout execution time	Checkout requests per minute	Orders per minute at 6 requests each	What usually puts a store on this row
1 second	2,400	400	Persistent object cache, lean checkout, healthy database
2 seconds	1,200	200	A typical store that has never been profiled
4 seconds	600	100	Cart fragments on every page, no object cache
8 seconds	300	50	Database lock contention once concurrency rises
16 seconds	150	25	Scheduled job backlog plus payment gateway retries

The WooCommerce Checkout Ceiling Table: sustainable checkout throughput at 40 entry processes, by checkout execution time.

The striking part of that table is not the top row. It is how far a store falls when execution time inflates, and inflation is exactly what heavy concurrency causes. A store measured at two seconds in October is not a store running at two seconds during the sale.

How to Measure Your Store’s Real Checkout Execution Time

Measure server time, not page load time. The two are routinely confused, and only one of them consumes an entry process. What you want is the time the server spends generating the checkout response, which you can read from a server timing header or from a query monitoring plugin on a staging copy.

Additionally, measure it three times: once on a quiet morning, once with a coupon applied, and once with a full cart and a shipping calculation. Those three numbers are usually not close to each other, and the worst of them is the one to plan against. Interaction responsiveness on the front end matters separately, and the Interaction to Next Paint metric is the current measure for it, but it is a different problem from server capacity. Where the seconds actually accumulate is the subject of our walkthrough on finding where checkout time is spent.

The 12-Week WooCommerce Black Friday Hosting Countdown

Each stage below ends in a gate. Passing the gate is what earns the right to move to the next stage; failing it means the schedule slips rather than the standard. Dates are for Black Friday on November 27, 2026.

Stage	Dates in 2026	Work	Go or no-go gate
Weeks 12 to 9	September 7 to October 2	Measure the checkout ceiling; fix the slow paths	Checkout execution time is known and has improved measurably
Weeks 8 to 5	October 5 to October 30	Rehearse peak load against a staging copy	A rehearsal at twice expected peak completes with no errors
Weeks 4 to 2	November 2 to November 13	Size the plan and migrate if the rehearsal demanded it	The final infrastructure has itself been rehearsed
Week 1	November 16 to November 27	Change freeze, monitoring, rollback drill	A tested restore exists and someone is rostered to watch

The 12-Week Peak Readiness Countdown: stages, dates and the gate that ends each one.

Weeks 12 to 9: Measure, Then Fix the Slow Paths

Begin with measurement, because every later decision is scaled by the checkout execution time. Only then start removing work from the request. The reliable wins are consistent across stores: a persistent object cache, database tables that have been cleaned of expired transients, and any plugin that runs on every page rather than only where it is needed.

The single most common offender in a WooCommerce store is the cart fragments request, which fires on every page view whether or not the visitor has a cart. Our post on stopping cart fragments from slowing every page covers the fix. Beyond that, the WooCommerce performance best practices are the canonical checklist for what belongs on a request path and what does not.

By the end of this stage you should be able to state your checkout execution time as a number and show that it moved.

Weeks 8 to 5: Rehearse the Peak

A fix that has not been tested under load is a hypothesis. This stage converts hypotheses into evidence by generating traffic that resembles a real sale against a staging copy of the store.

Rehearse twice. The first run establishes that the machinery works and usually finds something broken in the test itself. The second run is the one that counts, and it should be aimed at twice the peak you actually expect. Twice is not pessimism; it is the margin that absorbs the execution time inflation the ceiling table describes.

Weeks 4 to 2: Size the Plan and Move Early

If the rehearsal says the current tier cannot carry the peak, this is the window in which to move. Migrating in the final fortnight is the classic unforced error, because a migration changes the thing you spent eight weeks measuring and leaves no time to measure it again.

Moreover, the destination should be chosen for the capability it adds rather than for the size of its specification sheet. A store that needs a persistent object cache, a tuned database server, or a background worker that outlives a single request is describing a virtual private server with allocated resources rather than a larger shared container. Whichever tier you land on, rehearse again on the new infrastructure before the gate closes.

Week 1: The Change Freeze

Nothing ships in the final week. No plugin updates, no theme edits, no PHP version changes, no new payment methods, no clever last-minute banner. The freeze feels excessive right up until the moment it saves a sale.

Use the week for the things that carry no risk: confirm the restore actually restores, check that alert thresholds are set low enough to be useful, and put a named person on watch for the first hour of the sale. A monitoring dashboard nobody is looking at is decoration.

How to Rehearse Peak Load Without Taking the Store Down

A rehearsal is only useful if it resembles the event. Most WooCommerce Black Friday hosting load tests fail that standard by hammering the home page, which is cached and therefore free, and concluding that the store is bulletproof.

Building a Checkout Load Test That Resembles Real Buyers

Model the journey rather than a URL. A realistic script browses two or three products, adds one to the cart, applies a coupon, reaches checkout and places an order, with pauses between steps that resemble a person reading. Cookies must persist across the journey, or every request looks like a new visitor and the cart never fills.

Run it against staging, never production, and against a database that has been seeded with a realistic catalog and order history. An empty database returns query times that no live store will ever see. Guidance on ramp profiles and how to escalate load is in the k6 stress testing guide, which describes the shape of a run rather than a specific tool.

The Four Signals to Watch During a WooCommerce Black Friday Hosting Rehearsal

First, checkout execution time as concurrency rises. A flat line means headroom. A curve that bends upward tells you where the ceiling actually sits, and that inflection is the single most valuable output of the whole exercise.

Second, the background job queue. WooCommerce defers a great deal of work to scheduled actions, and when they fall behind the symptom is orders that appear stuck rather than a page that is slow. The Action Scheduler throughput notes explain how the queue drains and what limits it.

Third, database wait time, which is where contention shows up first. Fourth, payment gateway responses under concurrency, because a gateway that times out produces duplicate charges or orphaned orders depending on how your store handles the failure. The Stripe error handling documentation is a good model for the failure modes any gateway integration has to survive.

When WooCommerce Black Friday Hosting Needs More Than a Shared Plan

Shared hosting carries far more peak traffic than its reputation suggests, provided the caching is right and the checkout is lean. The honest trigger for moving to a larger tier of WooCommerce Black Friday hosting is a capability the container cannot provide, not a number of visitors.

It is worth noting what plan pages typically disclose. Our own shared hosting tiers publish site counts and storage, as nearly every plan page does. The concurrency figures that decide peak behavior are published on the WooCommerce plan specifically, which is the exception rather than the rule across this industry.

Shared, WooStart, VPS, Dedicated: A Peak-Load Comparison

Tier	Published limits	What it changes at peak	Choose it when
Shared tiers	5 to 20 sites, 15 to 60 GB SSD; concurrency not published	Nothing on its own; caching does the work	The store is small and the checkout is already lean
WooStart	40 entry processes, 3 GB memory, up to 3 CPU cores, 20 MB/s and 2,048 IOPS	Gives you a ceiling you can calculate	You want the numbers before you plan
KVM VPS	2 to 16 vCPU, 4 to 32 GB RAM, 50 to 150 GB SSD	Allocated resources, root, persistent services	A capability is blocked, not merely tight
Dedicated server	Whole machine, single tenant	Removes every neighbor from the equation	One store justifies the entire machine

A Peak-Load Comparison of the four tiers, by what each one actually changes during a sale.

Ultimately, the jump to a single-tenant dedicated machine is a decision about isolation rather than about raw capacity. Most stores that think they need one need a persistent object cache and a fixed checkout instead.

What AHosting Publishes That Makes Peak Planning Possible

AHosting has run hosting infrastructure from Southfield, Michigan since 2002, and the platform carries a published 99.9% uptime commitment. Availability, though, is not the interesting number for a store owner planning a sale, because a fully available server can still take sixteen seconds to take a payment.

The figures that matter are the concurrency limits, and the WooStart plan prints them: 40 entry processes, 3 GB of physical memory, up to 3 CPU cores, 20 MB/s of disk throughput and 2,048 IOPS. Those five numbers are the entire input to the ceiling calculation. A plan page that prints only storage and the word unlimited leaves you unable to compute anything at all, which is convenient for whoever wrote the page.

Check Your WooCommerce Black Friday Hosting Readiness

Rather than reading the ceiling table across, put your own two numbers into the check below. It assumes the published 40 entry processes and six uncacheable requests per order.

Check Your WooCommerce Black Friday Hosting Readiness

Two numbers: how long your checkout takes on the server, and how many orders you expect in the busiest hour.

1. Checkout execution time on the server

2. Orders you expect in the busiest hour

Pick one option in each row to see your checkout ceiling and the headroom it leaves.

See the published WooStart limits

The Change Freeze and the Rollback You Hope Not to Use

A rollback plan that has never been executed is a wish. The last stage of WooCommerce Black Friday hosting preparation exists to convert it into a procedure somebody has actually performed, on this store, with this data.

Restore a backup to a staging site and open the store. Place a test order. Confirm the order number, the payment record and the stock count all agree. That exercise routinely uncovers a backup that excludes the uploads directory or a database dump that predates a schema change, and finding it in November is considerably better than finding it during the sale.

Similarly, agree in advance what triggers a rollback and who decides. A threshold written down while everyone is calm is worth more than a judgment call made at two in the morning with orders queuing. Write down the checkout execution time at which you intervene, the error rate at which you disable a nonessential plugin, and the person whose call it is.

A Practical WooCommerce Black Friday Hosting Checklist

Work through the ten items below in order. Together they are what WooCommerce Black Friday hosting preparation amounts to in practice, and each one is cheap to do in September and expensive to improvise in November.

Measure checkout execution time on the server three ways: quiet, with a coupon, and with shipping calculated.
Confirm cart, checkout and account pages are excluded from page cache, and that nothing else is.
Remove the cart fragments request from pages that do not need it.
Add a persistent object cache and confirm it is actually being hit.
Clear expired transients and check for database tables that have never been cleaned.
Compute your checkout ceiling from your plan's entry process figure, then halve it.
Rehearse the full buying journey on staging at twice your expected peak.
Migrate, if the rehearsal demands it, no later than two weeks out, then rehearse again.
Freeze all changes one week out and restore a backup to staging to prove it works.
Set alert thresholds, and roster a named person to watch the first hour of the sale.

Notably, only two of those items involve buying anything. The rest are measurement and discipline, which is the honest summary of peak readiness: capacity planning is mostly the removal of avoidable work, and the plan tier is what carries whatever remains.

Frequently Asked Questions About WooCommerce Black Friday Hosting

How early should WooCommerce Black Friday hosting preparation start in 2026?

Specifically, twelve weeks out. Black Friday falls on November 27 in 2026, which puts the first measurement week in early September. That spacing exists for one reason: every fix worth making needs a rehearsal after it, and a rehearsal needs a quiet week to run in. The countdown table in this post sets a go or no-go gate at the end of each stage.

WooCommerce Black Friday hosting vs everyday hosting: what actually changes at peak?

Notably, the resources do not change at all; the mix of requests does. On an ordinary day most traffic is cached pages that cost nothing, so entry processes sit idle. During a sale the ratio inverts, cart and checkout requests dominate, and every one of them has to execute PHP. The plan you were happy with on Tuesday is being asked to do a different job.

What is the checkout ceiling, and how do I calculate it for 2026?

In practice, the checkout ceiling is the number of checkout requests your container can have in flight at once divided by how long each one takes. Forty entry processes against a two-second checkout gives 1,200 requests per minute. The arithmetic is Little's Law, and the number that matters is the one your store hits under load, not the one it measures on a quiet morning.

What does AHosting publish that makes WooCommerce Black Friday hosting capacity calculable?

Indeed, this is unusual enough to be worth stating plainly. The WooStart plan page prints 40 entry processes, 3 GB physical memory, up to 3 CPU cores, 20 MB/s disk I/O and 2,048 IOPS. Most plan pages print storage and the word unlimited. Without the entry process figure there is no ceiling to compute.

If my checkout takes 4 seconds, is WooCommerce Black Friday hosting on 40 entry processes enough?

Typically, yes, and that surprises people. Forty slots against a four-second checkout still clears 600 requests a minute, which is roughly 100 orders a minute at six uncacheable requests each. The danger is not the starting number. It is that four seconds becomes twelve under database contention, and the ceiling falls by the same factor.

AHosting WooStart vs a KVM VPS: which suits a store expecting 500 peak orders?

Ultimately, 500 orders across a peak hour is comfortably inside what 40 entry processes will carry, so the shared container is not the deciding factor. A KVM instance earns its price when you need a persistent object cache, a tuned database server, or a background worker that outlives a request. Buy the VPS for the capability, not for the order count.

When does WooCommerce Black Friday hosting need a change freeze, and how long?

As such, the freeze starts one week out and runs through the sale. Nothing ships after that date: no plugin updates, no theme edits, no PHP version change, no new payment method. A freeze is not caution for its own sake. It is what makes a rollback meaningful, because you can only revert to a state you have actually tested.

Why does my WooCommerce store slow down only during checkout under heavy traffic?

Furthermore, that pattern is diagnostic rather than mysterious. Catalog and category pages are served from cache and never reach PHP, so they stay fast no matter how many people arrive. Cart and checkout are excluded from cache by design, so they absorb the entire load, and they are also the slowest pages your store runs.

Does AHosting guarantee uptime during a 2026 Black Friday traffic spike?

Accordingly, the published commitment is a 99.9% uptime SLA, and it applies during a sale exactly as it does on any other day. That figure covers availability of the platform, not the speed of your own checkout code. A store can be fully available and still lose orders to a sixteen-second payment step.

How do I prepare my WooCommerce store for Black Friday traffic?

First and foremost, measure your checkout execution time before changing anything, because every later decision is scaled by that one number. Then fix the slow paths, rehearse the peak against a real load profile, size the plan while moving is still cheap, and freeze the site a week out. The countdown table sets the dates.

August 31, 2026