Hostinger Resource Limits Explained (Inodes, CPU & RAM)

What I Found After 12 Months on Hostinger Business

I've been running a Hostinger Business account alongside four other hosts since March 2025. In those 12 months I recorded 11 downtime incidents using UptimeRobot and manual logging. Seven of the 11 were not infrastructure failures, not DDoS attacks, not WordPress bugs. They were CPU throttle events — a budget I didn't fully understand ran out, and my site returned 503 errors until the hourly window reset.

That pattern led me to dig into exactly how Hostinger's resource limits actually work at the technical level: what "2 burstable CPU cores" means versus "2 dedicated CPU cores," what a CPU seconds quota is and how ordinary WordPress operations deplete it, why inode limits silently break things months before anyone notices, and what the correct upgrade path looks like once limits become a recurring problem.

This article documents all of that — the specs, the test data, the incident log, and the math. It is an educational explainer first. The commercial section appears at the end, after you have everything you need to make your own decision. I hold a Hostinger Business plan and I hold affiliate relationships with the alternatives I recommend — both are disclosed because both are true, and you deserve to know both when reading this.

Quick orientation: if you're here because your site just returned a 503 error during a traffic spike, jump to Section 7. If you suspect you're approaching the inode limit, go to Section 9. If you're ready to look at alternatives, Section 19 has the math on all three paths.

Test Methodology

What "Resource Limits" Actually Means on Shared Hosting

When you buy a shared hosting plan, you are renting space on a physical server that also houses hundreds of other websites. The server has a fixed amount of CPU, RAM, and disk — all shared across everyone on it. Resource limits are how the host ensures one account cannot consume everything and degrade performance for the rest.

This is a legitimate engineering approach. A server without per-account limits would be like a shared house with no agreement on electricity usage — one person running a cryptocurrency miner at 3 AM would push everyone else's bills up. Resource limits are the contract that makes shared hosting possible at shared hosting prices.

The problem with Hostinger's limits specifically is not that they exist — it's that they are tighter than several competitors at the same price point, and that the most consequential limit (the per-hour CPU seconds quota) is not transparently disclosed in the plan comparison. You can find the RAM, core count, and I/O numbers on the official documentation page. The CPU seconds model is described in vague fair-use language that doesn't tell you how many WooCommerce checkouts your hourly budget can handle before throttling begins.

This article fills that gap with real numbers.

The Full Resource Limits — Every Plan, Every Metric

Here is every published resource limit across all four Hostinger shared plans, from official documentation verified against our March 2026 testing. The Business plan row is highlighted because the majority of users are on this plan — and because it's the plan where resource limits become relevant at the traffic levels most small and medium sites actually reach.

The column worth your attention is "CPU Policy." Three of the four plans show "Burstable quota." That is not a marketing term — it is the technical description of a system that gives you burst access to CPU cores, subject to a per-hour spending budget. The next section explains exactly what that means and why it is the most consequential line in the entire table.

CPU Cores vs CPU Seconds — The Distinction Nobody Explains

The Business plan advertises "2 CPU cores." That sounds like dedicated processing power. It is not.

On shared hosting, "2 CPU cores" means burstable access to up to 2 cores on the shared physical server. You can use those 2 cores when demand is low and the server has headroom to give. What the spec sheet doesn't tell you is that this access is governed by a per-hour CPU seconds quota — a spending budget that your PHP processes draw down as they execute.

CPU seconds, in plain English: every time your server runs PHP code to handle a visitor request, that execution takes a measurable amount of time on the CPU. A simple blog page load might take 1.0 CPU seconds to execute. A WooCommerce checkout might take 5.5 CPU seconds. Your account gets an allocation of CPU seconds per hour. Think of it as a pre-paid calling card: you have X minutes, every call costs Y minutes, and when the card runs out, calls are queued until the next card activates.

The distinction from dedicated allocation is important. On a plan with guaranteed CPU, there is no budget — those cores are reserved for you and traffic spikes draw from your reserved share without depleting any finite pool. On a burstable plan, a traffic spike plus a background job running simultaneously can exhaust the hourly budget in minutes, leaving the remaining 50-plus minutes of the window with a throttled site returning 503s even though the spike has long since passed.

Hostinger does not publish the specific CPU seconds quota number. They describe the throttle system in fair-use language that does not give you a concrete limit to plan around. ChemiCloud's resource policy, by contrast, specifies that their WP Turbo plans use guaranteed allocation with no CPU seconds budget — the number doesn't exist because the model doesn't apply.

Your CPU Budget in Real WordPress Operations

The table below is the data no competitor has published. Every figure comes from our k6 load testing and server-side PHP timing on a Hostinger Business plan running a standard WooCommerce install in March 2026. Each operation was run 50 times and the median recorded.

The numbers that matter most here are the high-risk operations. A WooCommerce checkout at 5.5 CPU seconds costs more than five standard page loads. A WP-Cron execution at 11.0 CPU seconds costs more than eleven page loads. A bulk image resize at 26.0 CPU seconds costs more than twenty-six.

The double-trigger problem: the most common throttle pattern in our 12-month log was not sustained high traffic — it was WP-Cron firing at 10 AM while normal business-hours traffic was also arriving. WP-Cron's 11.0 CPU seconds fire simultaneously with, say, 15 concurrent page loads (15.0 CPU seconds). That 26.0-second burst in the same minute, combined with an already-active quota window, is enough to push many accounts into throttle territory. The fix for this specific pattern is in Section 17 — but the broader point is that the operations most likely to exhaust your quota are the ones you've scheduled to run automatically, not the traffic spikes you can see coming.

What Triggers 503 Errors — The Exact Sequence

Here is what happens inside the server from the moment a traffic spike arrives to the moment your visitors see a 503 error, and why the error continues long after the spike has ended.

Step 1: a burst of traffic arrives — in our most common incident pattern, roughly 80 concurrent users over a five-minute window. Step 2: WP-Cron fires in the same window, typically scheduled at 10 AM because that's the WordPress default. These two events combine their CPU demands within the same hourly quota window. Step 3: the combined CPU demand exhausts the hourly quota. At this point, the physical CPU cores may not be at 100% utilisation — the quota is an accounting limit, not a hardware limit. The cores could theoretically handle the load. But the quota says the account has spent its allocation for this hour. Step 4: LiteSpeed begins queuing new PHP requests rather than executing them immediately. Response times climb. Step 5: the queue fills beyond its threshold, and LiteSpeed begins returning 503 Service Unavailable to new visitors. The site appears down.

Step 6 is the one most people don't understand: the traffic spike ends. The 80 concurrent users disperse. WP-Cron finishes. But the quota is already exhausted for the current hourly window. PHP execution remains throttled for the remaining 40–55 minutes of the window — not because the server is still under load, but because the accounting says the budget is zero. Step 7: 503 errors continue arriving for an average of 34 minutes post-spike in our incident log. Clearing cache does not help. Refreshing the browser does not help. Restarting a plugin does not help. None of these actions restore a depleted CPU quota. Step 8: the next hourly window opens, the quota resets, and the site recovers — until the next time the same double-trigger pattern repeats.

What Triggers 508 Resource Limit Reached

The 503 error and the 508 error look similar to visitors — both mean the site is inaccessible — but they come from different underlying limits. Understanding the difference matters for diagnosing which limit you've hit.

A 508 Resource Limit Reached error comes from the entry processes limit — 30 on the Business plan. An entry process is a separate concept from a CPU second: it is one PHP process actively serving one incoming connection. When 30 PHP processes are running simultaneously (from 30 concurrent visitors, not accounting for background processes), the 31st visitor's connection is refused with a 508 rather than queued.

The 508 error resolves faster than a CPU throttle event. As existing PHP processes complete their execution and free their entry process slot, new connections can be accepted within seconds or minutes. The 503 error, by contrast, can persist for the remainder of the hourly CPU window regardless of whether active processes have completed.

If you see 508 errors in your error log alongside 503 errors on the same timestamp, you've likely hit both limits simultaneously — the entry process limit filled up at the same time the CPU quota was running low. This typically means your traffic concurrency has exceeded what the Business plan is designed to handle.

The Inode Limit — The Silent Limit Most Sites Never Notice Until It's Too Late

An inode is one record in the server's file system that represents one file or one directory. Nothing more complex than that. Your account's inode count is simply the total number of files and folders stored in it.

Hostinger's Business plan has a 600,000 inode limit. That sounds like an enormous number — until you inventory where inodes go on a typical WordPress site.

A standard WordPress installation uses roughly 25,000 inodes. WooCommerce with 500 products adds approximately 80,000 more. Twenty active plugins add another 30,000. A media library with a year's worth of uploads — images, PDFs, anything your content team has uploaded — adds 70,000 or more depending on whether WordPress has generated multiple thumbnail sizes for each image. LiteSpeed Cache's generated static page cache adds between 50,000 and 150,000 inodes depending on how many unique URLs your site has. A year of log files adds roughly 40,000.

Running total on a reasonably busy WooCommerce site after one year: approximately 350,000 inodes. After two years of uploads, a growing product catalog, and accumulating log files: you are past 600,000.

The insidious part is what happens when you hit the limit. The server treats an inode-exhausted account like a disk with no free space. FTP and SFTP uploads fail silently — the file transfer appears to complete, but the file doesn't appear on the server. No error message. You just wonder why the image you uploaded isn't there. WordPress core and plugin updates break mid-execution because the update process cannot create the temporary files it needs. Cache plugins stop writing new cached versions of pages. New WordPress users cannot be created. Any process that needs to create a new file fails — quietly, without telling you the inode limit is why.

The only fix when you're at or near the limit is to free inodes: delete log files (hPanel → File Manager → logs/ directory), clear plugin-generated cache files, remove unused media, and audit for duplicate or orphaned files. It buys time. It does not increase the ceiling.

The I/O Limit — What 2 MB/s Actually Means for WordPress

I/O — input/output — refers to the rate at which your server account can read from and write to disk. The Business plan limits this to 2 megabytes per second. That's the combined rate for all activity: serving files, writing to the database, writing cache files, reading plugins, everything.

For a low-traffic site serving mostly cached pages, 2 MB/s is rarely the bottleneck. For a site under meaningful load, it becomes relevant in ways that aren't immediately obvious.

LiteSpeed Cache works by writing static HTML files to disk so it can serve them without invoking PHP. When traffic is high and a lot of new pages are being cached simultaneously, LiteSpeed Cache is writing constantly — and that writing is consuming the I/O budget. A high-traffic spike where many uncached URLs are being hit for the first time means LiteSpeed Cache is actively making the I/O situation worse as it races to build the cache.

Database queries are the other primary I/O consumer. WooCommerce's product catalog, order history, and customer data all live in the MySQL database, which reads and writes to disk. When the I/O limit is approached, database query times increase as reads and writes are queued. This manifests as slow page load times that don't produce any visible error code — the site just becomes progressively slower under load until I/O demand eases.

The I/O limit is most commonly hit in two scenarios: a traffic spike where many uncached pages are being served and LiteSpeed Cache is generating new static files simultaneously, or a scheduled task like sitemap regeneration (8.0 CPU seconds and heavy disk reads) running during peak visitor hours.

RAM: What 1.536 GB Means Under Real Load

The Business plan provides 1,536 MB — 1.536 GB — of RAM. This sounds adequate for a single WordPress site. Under WooCommerce load it becomes the second most common ceiling after the CPU seconds quota.

Each PHP process handling a WooCommerce request uses between 128 MB and 256 MB of RAM, depending on how many active plugins are loaded and how complex the operation is. A simple checkout with 20 active plugins will typically sit at the higher end of that range — call it 200 MB per concurrent PHP process. At 1,536 MB total, that means seven concurrent WooCommerce PHP processes can fill the RAM allocation entirely. The eighth process cannot be allocated. PHP kills it. The visitor sees a 500 Internal Server Error or a white screen.

There is an important distinction here between PHP memory limit and the account's RAM allocation. WordPress's PHP memory limit (typically set at 256 MB in wp-config.php) controls the maximum memory a single PHP process can use. The account RAM allocation controls the total across all simultaneous processes. You can have a PHP memory limit of 256 MB and a 1,536 MB RAM allocation, and still hit the account ceiling with 6–7 concurrent requests, because the limit is on the account-level total, not per-process.

Under WooCommerce checkout load at 6–8 concurrent customers — not an unusual number during any meaningful promotion — the RAM ceiling is reachable before the CPU quota becomes the primary constraint.

LiteSpeed Cache — What It Helps and What It Doesn't

LiteSpeed Cache is the caching plugin installed on virtually every Hostinger WordPress site. It is genuinely useful — but there is a widespread misconception that it protects against resource limit problems. It protects against one category of them.

For anonymous page views — a logged-out visitor loading your homepage, a blog post, a product listing — LiteSpeed Cache serves the request from a pre-built static HTML file without invoking PHP at all. No PHP execution means no CPU seconds consumed for that request. This is significant for content-focused sites with mostly anonymous traffic. If 80% of your visitors are loading pages that are fully cached, you are running at 20% of the CPU cost those page loads would otherwise generate.

For WooCommerce, the protection is partial and has hard limits. Cart pages are excluded from cache by default because they contain user-specific data. Checkout pages are excluded because they process payments and require a live PHP execution for every step. Any logged-in user — a returning customer who created an account — bypasses the cache entirely for every page they load. The operations that consume the most CPU seconds in our test data (5.5 seconds per checkout, 11.0 per WP-Cron) are completely outside LiteSpeed Cache's protection envelope.

WP-Cron is worth a specific note: it fires based on WordPress's internal scheduler, not on visitor traffic. Caching a page has no effect on whether WP-Cron runs or how much CPU it consumes when it does. If your WP-Cron is scheduled to run at 10 AM, LiteSpeed Cache does nothing to prevent that 11.0-second CPU draw from hitting your quota window.

The I/O caveat is also worth stating clearly: LiteSpeed Cache writes static HTML files to disk. That writing consumes I/O bandwidth from your 2 MB/s account limit. During high-traffic periods where the cache is actively building, LiteSpeed Cache is itself a contributor to I/O pressure — not a relief from it.

What Hostinger Doesn't Tell You — The Documentation Gaps

Hostinger's official parameters and limits documentation page lists CPU cores, RAM, I/O, IOPS, entry processes, and inodes. What it does not list is the per-hour CPU seconds quota — the number that actually determines when throttling begins on the shared plans. The documentation acknowledges fair-use CPU policies in general terms but gives you no number to plan around.

I submitted a support ticket in March 2026 asking specifically for the CPU seconds quota on the Business plan. The reply I received was: "The CPU limit is managed dynamically based on fair use, and we do not publish specific numbers as these can vary based on server load conditions." This is the answer you get when you ask the question directly. No number. No threshold. No way to know how close you are to throttling until you're already throttled.

Compare this to ChemiCloud's published resource policy, which specifies that their WP Turbo plans use 100% guaranteed CPU allocation — the concept of a CPU seconds budget does not apply because the allocation model is different. You know exactly what you're getting because the policy difference is explicit.

The inode limit is technically documented — 600,000 inodes appears in the parameters table. What is not documented is the practical consequence: that hitting the inode limit causes silent FTP failures, invisible WordPress update breakage, and cache writing failures with no error message. The documentation says the limit exists. It does not explain what breaks when you hit it.

12 Months of Throttle Incidents — My Personal Log

Here is the complete incident log from our 12-month monitoring period. Seven of eleven incidents were CPU throttle events. Four were other causes: one server-side infrastructure issue on Hostinger's end, one DNS propagation issue unrelated to Hostinger, and two incidents caused by a misconfigured plugin that generated excessive DB queries.

The pattern is clear. CPU throttle events account for 7 of 11 incidents and were concentrated between 10 AM and 2 PM EST in every case except incident 9 (a 7 PM product launch). The two campaign-related incidents — 9 and 11 — are the most significant from a business perspective: these were planned, intentional traffic events where the site returning 503 errors directly cost revenue. The throttle was predictable. The product category is the problem, not the campaign itself.

Who Actually Hits the Limits — and When

Not every site on Hostinger Business will experience CPU throttling. The Business plan is reasonable infrastructure for a certain category of site. The problem is that the category where it works well does not overlap cleanly with the category Hostinger's marketing targets — multi-site plans, WooCommerce storefronts, and agencies are all featured in the pitch. Those are also the use cases most likely to encounter the limits.

How to Detect Whether You're Being Throttled Right Now

The first place to look is hPanel's error log. Log in, navigate to the Hosting section, and find the Error Logs link. Filter by today's date or the date of any incident you suspect was throttle-related.

In the error log, you are looking for three things: entries containing "508 Resource Limit Reached" (entry process limit hit), "CPU Limit Exceeded" (CPU quota hit), or clusters of PHP timeout errors appearing within a short time window. A single isolated error suggests a one-off PHP problem. A cluster of 10–20 identical errors within a 15-minute block in the morning is a throttle signature.

For ongoing monitoring without manual log-checking, UptimeRobot's free plan is the most practical tool. Set up two HTTP monitors: one on your homepage URL, one on your checkout URL (for WooCommerce sites). The checkout URL monitor will catch 503s that affect dynamic pages while static cached pages are still serving — giving you a more accurate picture of WooCommerce availability specifically. Set the check interval to 5 minutes. When an incident occurs, UptimeRobot will send an alert and log the downtime start and end times, giving you the data you need to correlate with your error logs and identify the pattern.

How to Delay Hitting the Limits (These Are Delay Tactics, Not Fixes)

There are several configuration changes that reduce your CPU seconds consumption and inode accumulation. None of them eliminate the underlying constraint. They buy time and reduce the frequency of throttle events. Here they are in order of impact.

Move WP-Cron to server cron. This is the highest-impact single change for most sites. By default, WordPress fires WP-Cron when a visitor loads a page. This means cron jobs fire during visitor traffic — the double-trigger pattern. Server cron runs WP-Cron on a schedule independent of visitor activity, ideally during off-peak hours (3 AM–5 AM). To implement this: add define('DISABLE_WP_CRON', true); to wp-config.php, then create a server cron job in hPanel → Cron Jobs running php /home/[account]/public_html/wp-cron.php every 15 minutes at hours 3–5 AM. This alone eliminated two of our seven throttle incidents in the second half of the monitoring period.

Audit and reduce active plugins. Every active plugin adds PHP load to every page request. A plugin that adds 50 ms of PHP execution time on every page load costs 0.05 CPU seconds per visit — at 1,000 daily visits, that's 50 CPU seconds per day of overhead from one plugin. Audit your active plugins, deactivate anything unused or redundant, and prefer plugins that load conditionally (only on relevant pages) over plugins that load globally.

Inode cleanup — scheduled maintenance. Set a calendar reminder for quarterly inode maintenance: delete contents of the /logs/ directory in File Manager, clear LiteSpeed Cache's generated static files (LiteSpeed Cache → Manage → Purge All), and run the WordPress media cleanup to delete unattached media files.

Pre-optimise images before upload. Uploading large images triggers server-side resize operations — up to 26.0 CPU seconds for a batch of 20. Running images through an optimisation tool (Squoosh, TinyPNG, or a local script) before uploading reduces both the resize CPU cost and the inode count per image since smaller originals generate smaller thumbnails.

Object caching with Redis (if available on your plan) can reduce database query load by storing query results in memory rather than re-running them against disk on every request. This helps with both CPU and I/O consumption for database-heavy operations like WooCommerce product pages.

These are delay tactics. If your site is regularly hitting resource limits, the real answer is moving to a host with guaranteed resource allocation.

The 4 Signals That Mean It's Time to Move

Four specific conditions indicate that delay tactics are no longer the right response and the infrastructure itself needs to change.

Signal 1: CPU throttle events more than once per week. If you are seeing 503 clusters in your error log on multiple days per week after implementing the WP-Cron server cron fix and reducing plugin count, the traffic level and operation mix of your site has structurally exceeded what the Business plan's quota can accommodate. You are not configuring your way out of this.

Signal 2: 503 errors during planned campaigns or promotions. If you send an email to your list or run a paid campaign and your site goes down during the resulting traffic, shared hosting has become a direct revenue risk. The Business plan's CPU quota is not designed for traffic spikes of the kind that marketing campaigns generate. Incidents 9 and 11 in our log were both campaign-triggered, both predictable in retrospect, and both cost actual revenue.

Signal 3: inode count above 400,000. Check your current inode count in hPanel → Files — it's shown in the storage usage section. If you're at 400,000 or above, you have less than 50% buffer remaining and a growing site will hit the ceiling within months. At that point, the cleanup work required to stay under the limit becomes a significant ongoing maintenance burden that wouldn't exist on a host without an inode limit.

Signal 4: WooCommerce checkout errors during normal traffic, not just spikes. If checkout is returning errors on a typical Tuesday afternoon with no campaign running, the base traffic level of your store has exceeded the plan's sustained capacity. This is the hardest signal to act on because the errors are intermittent and easy to rationalise as one-off issues — but if they recur consistently at similar traffic levels, the plan is undersized for your store.

What to Move To — The Three Upgrade Paths

There are three upgrade paths from Hostinger Business, each addressing a different combination of budget, site type, and technical requirement.

Path A — ChemiCloud WP Turbo (Guaranteed Shared, No CPU Budget)

ChemiCloud's WP Turbo plan gives 3 CPU cores with 100% guaranteed allocation and 3 GB RAM — roughly double the CPU and RAM of Hostinger Business, with an entirely different allocation model. There is no CPU seconds budget because guaranteed allocation doesn't work that way: the 3 cores are reserved for your account, and traffic spikes draw from that reserved share without depleting any finite pool. A WP-Cron run at 10 AM while a campaign drives traffic is not a throttle risk because there is no hourly quota to exhaust.

ChemiCloud is the right path if you want to stay on shared hosting pricing — the intro rate is competitive with Hostinger's renewal pricing — and your site type doesn't require dedicated resources. Content sites, moderate WooCommerce stores under 1,000 daily visitors, and agencies hosting client sites that aren't generating heavy concurrent checkout traffic are all well-served here. See the full comparison in our ChemiCloud vs Hostinger comparison.

Path B — ScalaHosting Managed VPS (Dedicated AMD EPYC, Zero Throttle)

ScalaHosting's Managed VPS runs on AMD EPYC 9474F processors — ranked approximately 32nd out of 1,178 server CPUs on PassMark's multi-thread benchmark, top 3%, with 4.1 GHz turbo clock speeds, DDR5 RAM, and PCIe 5.0 NVMe SSDs. For reference, Hostinger's shared servers use AMD EPYC 9354P CPUs, ranked approximately 62nd on the same benchmark — 30 positions slower. The hardware difference matters, but the allocation difference matters more.

On a managed VPS, your CPU cores are dedicated to your virtual machine. There is no shared server pool, no CPU seconds budget, no hourly quota. CPU throttling is physically impossible because no other account can claim your resources. The same is true for RAM and I/O — what you allocate is what you have, uncontested. A 5-minute traffic spike that would exhaust Hostinger's CPU quota and cause 503s for the following 34 minutes runs clean on a VPS because the dedicated cores can handle it without depleting any finite budget.

The Entry Cloud plan — ScalaHosting's smallest VPS tier at 2 dedicated cores + 2 GB RAM — is worth specific attention as the stepping-stone option. It's priced closer to premium shared hosting than to traditional VPS, and it gives you dedicated resources, no throttle, and the full ScalaHosting stack without jumping straight to the larger VPS configurations. If you've been hesitating because "VPS" sounds expensive, the Entry Cloud plan is the number to look at first.

One more thing worth noting: SPanel — ScalaHosting's control panel — uses approximately 1 CPU core and 256 MB RAM as overhead. cPanel, the industry-standard alternative, recommends a minimum of 2 cores and 4 GB RAM. You get back the resources the control panel itself would have consumed. On a tight VPS allocation that difference is meaningful: a 2-core ScalaHosting VPS with SPanel delivers more usable capacity than a 2-core VPS with cPanel would.

Resources scale individually: add 1 CPU core for $3/month, 1 GB RAM for $1/month. No locked bundle upgrades, no plan jump required when you need a bit more headroom. Independently owned — Chris, Vlad, and the Scala team have direct accountability in a way that conglomerate hosts do not. Free migrations, free malware scans via SShield. Use coupon THATMY at checkout. See the full breakdown in our ScalaHosting managed VPS review.

Path C — Cloudways (Dedicated Cloud, Code CLOUDS2022)

Cloudways deploys your site on a dedicated instance from DigitalOcean, AWS, or Google Cloud. Dedicated cloud infrastructure means no CPU seconds budget, no I/O throttle, no entry process limits — the resource model is fundamentally different from shared hosting in the same way a VPS is, but with the cloud provider's elastic scaling behind it. The right path for developers who want control over the infrastructure layer and for stores that are growing fast enough that even a VPS might need scaling in 12 months. Month-to-month billing, no annual contract.

Use promo code CLOUDS2022 — it applies a $30 credit to your first invoice. At the $11/month DigitalOcean Basic entry point, that makes the first 2.7 months effectively free. Full details in our Cloudways pricing breakdown.

Side-by-Side: What Each Path Actually Gives You

The right path depends on your situation. For sites that want guaranteed shared resources without VPS pricing, ChemiCloud. For WooCommerce stores where a throttle event has cost revenue, or for any site where dedicated isolation is the requirement, ScalaHosting. For developers and fast-growing stores that want the cloud provider infrastructure layer, Cloudways. All three eliminate the CPU seconds quota problem entirely.

Where Do the Alternatives Actually Stand?

Frequently Asked Questions

What is Hostinger's CPU limit on the Business plan?

The Business plan gives access to 2 burstable CPU cores — but 'burstable' is the critical word here. The plan does not give you 2 dedicated cores. It gives access to up to 2 cores on the shared physical server, subject to a per-hour CPU seconds quota. Think of this as a spending budget for processing power: your account gets a set number of CPU seconds per hour. Standard WordPress page loads consume roughly 1.0 CPU seconds each. A WooCommerce checkout consumes approximately 5.5 CPU seconds. A single WP-Cron execution consumes approximately 11.0 CPU seconds. Once that per-hour budget is exhausted, PHP execution is queued or throttled — which is why traffic spikes trigger 503 errors and why those errors often persist for 30–40 minutes after the spike itself has ended.

Why does my Hostinger site show 503 errors during traffic spikes?

The sequence works like this: a burst of traffic — say 80 concurrent users over five minutes — combined with any background operations running simultaneously (WP-Cron is the most common trigger) can exhaust your account's hourly CPU seconds quota faster than expected. Once the quota is gone, LiteSpeed begins queuing incoming PHP requests. When the queue fills, it returns 503 Service Unavailable to new visitors. The critical thing to understand is that the spike does not need to be ongoing for the 503s to continue — your quota is exhausted for the remainder of the current hourly window. In our 12-month testing, the average CPU throttle incident lasted 34 minutes from onset to recovery, even when the traffic spike that caused it lasted fewer than 10 minutes. Refreshing the browser or clearing cache does not fix this. Only the reset of the hourly CPU window does.

What is the inode limit on Hostinger Business and why does it matter?

The Business plan has a 600,000 inode limit. An inode is a file system record — one inode per file or directory. So 600,000 inodes means 600,000 total files and folders. That sounds generous until you add it up: a standard WordPress installation uses roughly 25,000 inodes. WooCommerce with 500 products adds approximately 80,000 more. A year of log files can consume 40,000 inodes. Plugin cache files — especially LiteSpeed Cache's generated static files — can consume 50,000 to 150,000 depending on site size. A media library of moderate size adds tens of thousands more. A busy WooCommerce site can approach 600,000 within a year without anyone noticing — until something breaks. When the inode limit is reached, FTP and SFTP uploads fail silently (no error message, the file simply doesn't appear), WordPress core and plugin updates break, and no new cache files can be written.

Does LiteSpeed Cache fix Hostinger's resource limit problem?

It helps with anonymous page views — but not with the operations that consume your CPU budget fastest. When a logged-out visitor loads a cached page, LiteSpeed serves it directly from static cache without invoking PHP at all. This is genuinely useful for content-focused sites. However, LiteSpeed Cache provides no protection for WooCommerce checkout flows (each runs a full PHP/database cycle), cart pages and any logged-in user session, WP-Cron jobs (these run on a schedule regardless of cache state), or I/O-heavy operations like sitemap regeneration. Critically, LiteSpeed Cache's own cache-writing process consumes disk I/O — which means on a Business plan with a 2 MB/s I/O limit, high-traffic periods where cache is being built can actually contribute to I/O throttling. LiteSpeed Cache is a useful performance tool, not a resource limit solution.

How do I check if my Hostinger site is being CPU throttled right now?

Log into hPanel, navigate to the Hosting section, and look for the Error Logs link. Filter by the date of any incident. CPU throttle events will appear as '508 Resource Limit Reached', 'CPU Limit Exceeded', or as clusters of PHP timeout errors concentrated within a short time window. If you see multiple errors in a 10–30 minute block during morning business hours (10 AM–2 PM EST is the peak window in our data), you are almost certainly looking at a CPU throttle event rather than an infrastructure failure. For ongoing monitoring, UptimeRobot's free plan allows 5-minute interval checks — set up an HTTP monitor on your homepage and your checkout URL separately. The checkout URL monitor will catch 503s that affect dynamic pages but miss cached static ones.

What is the difference between Hostinger's CPU cores and ChemiCloud's?

The difference is the allocation model, not just the number of cores. Hostinger's Business plan gives access to 2 burstable cores — you can use up to 2 cores during low-demand periods, subject to a per-hour CPU seconds quota. When that quota is exhausted, PHP execution is throttled even if the physical cores are idle. ChemiCloud's WP Turbo gives 3 cores with 100% guaranteed allocation — those 3 cores are reserved for your account without any CPU seconds budget to exhaust. A traffic spike on Hostinger depletes a finite quota and causes 503s. The same spike on ChemiCloud consumes your guaranteed allocation without depleting any budget, so no throttle occurs.

When should I upgrade from Hostinger to a VPS?

Four signals indicate the time has come. First: CPU throttle incidents happening more than once per week — at this frequency, the throttle is structural, not a traffic anomaly. Second: 503 errors appearing during planned campaigns or promotions — if you cannot run a marketing campaign without your site returning errors, shared hosting is a liability. Third: your inode count exceeding 400,000 when you check it in hPanel → Files — you have less than 50% buffer remaining and a busy site will hit the ceiling within months. Fourth: WooCommerce checkout errors appearing during normal traffic, not just spikes. When any of these four signals appear consistently, ScalaHosting's Managed VPS is the right move — AMD EPYC 9474F CPUs (top 3% on PassMark), 2 dedicated cores, 4 GB RAM, and resource limits are physically impossible on a properly isolated VPS. Use coupon code THATMY at checkout.

Is Hostinger's Business plan enough for WooCommerce?

For a WooCommerce site under about 500 daily visitors with no scheduled promotions and WP-Cron moved off the default schedule, the Business plan may be sufficient. Beyond that threshold — or once WP-Cron fires during peak traffic — the math works against you. Each WooCommerce checkout consumes approximately 5.5 CPU seconds. A WP-Cron execution consumes approximately 11.0 CPU seconds. A single WP-Cron run during a moderately busy period consumes the equivalent of two full checkout cycles. At roughly 5 concurrent checkouts plus one WP-Cron fire in the same hourly window, the CPU seconds quota is under serious pressure. RAM is the secondary constraint: each WooCommerce PHP process uses 128–256 MB, and at 1.536 GB total RAM, six concurrent checkout processes approach the ceiling. For a WooCommerce store where a few hours of 503 errors during a product launch means lost revenue, ChemiCloud's WP Turbo (guaranteed resources at shared pricing) or ScalaHosting's Entry Cloud (2 dedicated AMD EPYC cores, zero throttle — coupon THATMY) are the more appropriate infrastructure choices.

My Final Summary

Hostinger's Business plan works exactly as advertised for the category of site it's designed for: a small blog under 500 daily visitors with minimal PHP-heavy operations and no WooCommerce checkout flow. If that is your site, the limits here will never become your problem, and Hostinger's pricing is hard to argue with.

If your site is outside that category — WooCommerce, marketing campaigns, automated cron jobs, growing traffic — the CPU seconds quota and the inode limit are not hypothetical risks. They are the direct cause of 7 of 11 measured incidents on a Business plan that was properly configured and maintained. The documentation gap around the CPU seconds model means you may not know the limit exists until you've already been throttled through a campaign that mattered.

The practical upgrades: ChemiCloud WP Turbo for guaranteed shared resources at shared pricing. ScalaHosting Managed VPS for zero-throttle dedicated AMD EPYC resources — use coupon THATMY — with individual resource scaling at $3/core and $1/GB that makes growing out of your plan frictionless. Cloudways for dedicated cloud with code CLOUDS2022 saving $30 on the first invoice. All three address the core problem that Hostinger Business cannot solve within its architecture: a shared resource model with a finite hourly CPU budget.

If you're running a WooCommerce store and have experienced even one throttle-related checkout failure, that incident has already cost more in lost revenue than a year's difference in hosting cost between Hostinger and a guaranteed-resource alternative. That is the math worth running before the next campaign.