How Much Traffic Can Cheap Hosting Handle for a Store?

Cheap shared hosting can comfortably run a small store with light, steady traffic — think a modest catalogue and a handful of orders a day. Where it falls over isn't total visits per month; it's concurrent checkouts. A bargain plan will serve thousands of product-page views fine (those can be cached) and then choke when a dozen people try to check out at the same time, because checkout can't be cached and there aren't enough PHP workers to go around. Understanding that distinction tells you exactly when cheap hosting stops being enough.

Why "visits per month" is the wrong number

Hosts advertise monthly visit allowances and "unlimited bandwidth" because those numbers sound reassuring, but they describe the easy traffic. A product page or blog post can be served from cache or a CDN without touching PHP or the database, so a store can handle huge numbers of those. The hard traffic is the cart and checkout: dynamic, per-user, uncacheable requests that each run PHP and hit the database. Your real ceiling is how many of those your plan can process at once — which the marketing rarely mentions.

PHP workers are the real capacity limit

A PHP worker is a process that handles one dynamic request at a time. A checkout ties up a worker for the whole transaction — validating the cart, reading and writing the database, calling the payment gateway, writing the order. Cheap shared plans often provide very few workers (sometimes only one or two), so once that many checkouts are in flight, the next shopper waits in a queue and the site feels frozen. Managed store plans advertise more workers precisely because that's what a store consumes; Kinsta's store-ready tier, for example, allocates four PHP workers for concurrent checkouts. The full requirements picture is in WooCommerce hosting requirements.

What caching can and can't rescue

Full-page caching and a CDN dramatically raise how much browsing traffic a cheap plan can take, and object caching (Redis) reduces database load, so caching genuinely helps — up to a point. But by design, carts, checkout and account pages are excluded from full-page caching because they're personal and constantly changing. So caching buys you a lot of headroom on the catalogue and almost none at the checkout. A store that's slow specifically during checkout has a worker/capacity problem that more caching won't fix.

Signs you've outgrown cheap hosting

Watch for these: checkout slows or errors when a promotion drives a burst of buyers; the admin dashboard crawls while the store is busy; you see 503 or "resource limit reached" messages; or your host emails about CPU/entry-process limits. Any of those means concurrent demand is exceeding your plan's capacity. A single sluggish product page is a caching or plugin issue; a checkout that stalls under load is a hosting-capacity issue, and it costs you real orders at exactly the wrong moment.

When to move up, and to what

Move before the busy season, not during it. A managed WooCommerce host (from about $21/mo, advertised Sep 2026) or a managed cloud server like Cloudways (from $11/mo) gives you the workers and memory a store needs, plus staging and scaling. Our best ecommerce hosting ranking lays out the options by capacity and renewal price, and if a specific event is coming, plan ahead with scaling a store's hosting for sales spikes.

What actually happens when a cheap plan maxes out

When concurrent demand exceeds a cheap plan's capacity, the failure is rarely a clean "down" message — it's a slow bleed that costs orders. First the site gets sluggish as requests queue for a free PHP worker. Then shoppers see spinning checkout buttons, gateway timeouts, or a "resource limit reached" (HTTP 503) page. Some abandon; some retry, which adds even more load. Meanwhile your own admin dashboard crawls, so you can't even see what's happening in real time. On oversold shared hosting, a host may also throttle or temporarily suspend a site that trips its CPU or entry-process limits, taking you fully offline at the worst possible moment. The insidious part is that none of this shows up in a quiet test — it only appears under the concurrent load of a good day, which is exactly when you can least afford it. That asymmetry is why store owners who wait for a problem to appear before upgrading almost always end up upgrading during an outage.

A rough way to estimate the capacity you need

You don't need a load-testing lab to sanity-check a plan; a back-of-envelope estimate helps. Take your busiest expected hour and estimate the orders in it, then remember each checkout occupies a PHP worker for the several seconds it runs — validating the cart, writing to the database, and waiting on the payment gateway. If a checkout holds a worker for roughly five seconds and you expect a burst of, say, 60 checkouts crammed into a few minutes, you can easily need several workers just for checkout, on top of the workers serving uncached cart and account pages. Add headroom, because real traffic is bursty rather than evenly spaced, and because a slow third-party gateway response holds the worker longer. A plan with one or two PHP workers simply cannot absorb that; a managed store plan or a sized cloud server with more workers can. When in doubt, size for your best day, not your average one — the average day was never the problem.

The bottom line: judge a plan by how it behaves under concurrent checkout load, not by the reassuring monthly-visit number on the sales page. Cheap shared hosting is a legitimate place to launch and validate a store idea, but it has a hard, usually undisclosed ceiling on simultaneous buyers, and you'll hit it at the exact moment success arrives. Plan your upgrade path before you need it, watch for the warning signs, and treat moving up as a normal step in a store's growth rather than an admission that something went wrong.