WordPress Hosting Limits: Why Your Site Errors When You Are Busiest

The website did not crash. That is the part owners find hardest to believe afterwards. The server was running, the database was healthy, nothing was hacked, and yet for the better part of an hour a large share of visitors got a blank error page instead of a working shop.

Picture a craft brewery in Kilkenny that sells online. I have watched this pattern play out on enough hosting accounts that the specifics here are a composite, but every step of it is real. On a Friday afternoon they announce a small-batch release on social. It lands. Within a few minutes the post is shared around, and a few hundred people all open the shop in roughly the same ten-minute window to grab a case before it sells out.

That is exactly when the errors start. Not a slow page. An error page. The harder the release went, the more people saw it. Their best day in months, and the website chose that moment to say no.

"Unlimited" was a marketing word, not an engineering one

Most cheap hosting is sold on the promise of unlimited everything: unlimited visits, unlimited bandwidth, unlimited sites. None of it is true in the way it reads. Every shared account sits inside hard limits, and the most important one is not storage or bandwidth at all. It is concurrency: how many of your visitors' page requests are allowed to run at the same instant.

Two ceilings do most of the damage here, and neither is on the sales page.

The first is memory. WordPress itself is conservative by default. As the official WordPress documentation sets out, the front end runs on a 40 MB memory limit out of the box, 64 MB for multisite, with the admin area allowed up to 256 MB. Those defaults are fine for a quiet brochure site. A WooCommerce shop under load wants far more headroom, and on shared hosting you often cannot raise the ceiling because the host has capped it at the server level.

The second ceiling is the one that actually trips on a busy day: a limit on simultaneous requests. On the CloudLinux platform that underpins a huge share of budget hosting, this is the Entry Process limit, and the vendor's own documentation is blunt about what it does. It caps the number of scripts your site can run at the same moment, and standard shared plans are typically set somewhere around 20, with higher tiers near 40. Reach it, and the server stops accepting new requests and returns an error code instead.

So what does that mean for the brewery? It means that no matter how many cases they had to sell, only around twenty people could be served a page at any given instant. Customer twenty-one onwards got the door shut in their face.

Why the maths breaks at exactly the wrong moment

Here is the mechanism, in plain terms, because once you see it you cannot unsee it.

A WordPress page is not a file sitting ready to send. It is built fresh on each request by PHP, which talks to the database, assembles the page, and hands it back. The processes that do this work are called PHP workers, and each worker can handle exactly one request at a time. If a page takes one second to build and you have six workers, you can build six pages a second. Request number seven waits in a queue. If the queue is already full, it does not wait. It is refused, and the visitor gets a 503 error.

On a normal Tuesday this is invisible. Traffic trickles in, workers are free, every request is served in a blink. The ceiling is up there in the dark and nobody ever touches it.

Then comes the good day. A release, a mention, a busy bank holiday, the Friday rush. Suddenly hundreds of requests arrive in the same few seconds. The workers fill instantly, the queue fills behind them, and every request after that is turned away. The site does not slow down and recover. It hits the wall and bounces people off it, over and over, for as long as the surge lasts.

And your visitors are not the only thing competing for those workers. WordPress runs its own background jobs through a built-in scheduler, and on a busy site those can fire several tasks at once. Add the steady stream of bots and crawlers that hit every public site around the clock, and a slice of your worker pool is already spoken for before a single real customer arrives. So the twenty you were quietly allocated is rarely twenty in practice. It is twenty minus whatever the background noise is using at that exact second.

There is a second lever too, and it is page speed. The longer each page takes to build, the longer a worker stays occupied, and the fewer requests you clear per second. A site weighed down by heavy plugins holds each worker for longer, so you reach the ceiling with even fewer visitors than the number on the plan suggests. Slow and fragile turn out to be the same problem wearing two hats.

That is the cruel logic of a resource limit. It does not punish your quiet days. It punishes your best ones. If you want the full picture of what governs a site under load, our complete guide to WordPress performance for business owners walks through the whole chain, and it is worth understanding what a sudden surge of traffic actually does to a site before you find out the hard way.

The limit nobody put on the invoice

The thing that makes these ceilings so frustrating is that you almost never see them coming. There is no warning email at 80 per cent. There is rarely a line on your bill that says "maximum 20 simultaneous visitors". The first time most owners learn the limit exists is the moment they breach it, usually while their phone is buzzing with people asking why the site is down.

What makes it worse is that the error points you at the wrong suspect. A 503 looks like something inside your site has broken, so the natural response is to go hunting through WordPress. Owners deactivate plugins one by one, switch themes, clear caches, sometimes pay someone to rebuild a site that was never at fault. The code was fine the whole time. The ceiling was external, set by the host, and invisible from inside your own dashboard. Hours of emergency fixes get burned on a problem that no amount of tidying your own site can reach.

Some hosts go a step further and turn the limit into a charge. Exceed your resource allowance often enough and the account gets throttled, or flagged for a forced upgrade, or in the worst cases suspended for "excessive use" of a plan that was advertised as unlimited. The success that should have been a good news story becomes a support ticket and a bigger invoice.

I will own an operational misjudgement of my own here. Early on, I signed off on a maintenance window for a client site based on a resource dashboard that looked comfortably within limits. What the dashboard averaged over an hour, it hid over any given second. A scheduled job and a small traffic bump landed together, the concurrency spiked for ninety seconds, and visitors caught errors during a window I had called safe. We changed how we measured after that. Averages lie about the moments that matter.

This is the gap between a host that sells you space and a host that runs an operation. Anyone can rent you a slice of a shared server. Far fewer are watching what happens to it the second things get busy.

What hosting that does not fall over looks like

Strip away the brand names and the fix is not complicated to describe. Hosting that survives your best day does four things.

It serves most visitors without running any code at all. The reason concurrency limits hurt is that every visitor consumes a worker. But the brewery's shop front, its product listings and its story pages are the same for everyone. A proper page cache builds those once and serves the saved copy to the next thousand visitors instantly, without touching PHP, the database or the worker pool. The limited resource is reserved for the requests that genuinely need it.

It gives you real allocated resources, not a sliver of a crowded box quietly competing with hundreds of strangers. It is watched by people, so a surge triggers a response rather than a silence. And it does not turn your growth into a penalty, because the headroom you need is part of the plan rather than an overage line.

Measured against that standard, this is the part of the job that managed hosting is supposed to own. Web60 runs every site on enterprise-grade Irish infrastructure built on a managed WordPress stack: Nginx, PHP-FPM, Redis object caching and FastCGI page caching working together. In practice the page cache means the overwhelming majority of your visitors are served a ready-made copy and never go near the worker limit, so the kind of surge that takes a cheap shared plan down barely registers. A real Irish-based operations team watches the platform rather than waiting for your ticket. And because everything is included for a flat €60 a year, a good day does not arrive with an excess-use charge attached.

One honest limit, because no amount of caching is magic. A cached page only works for content that is the same for everyone. The checkout itself, a logged-in account, a live basket: those are personal by nature, they cannot be served from cache, and they will always consume a real worker. So a flood of simultaneous checkouts still leans on genuine capacity. The difference is that proper infrastructure sets that ceiling far higher and watches it, instead of cutting you off at twenty and emailing you about it on Monday.

When a tight limit genuinely will not matter

I will be straight about the case where none of this applies. If your website is a simple brochure, a few pages with your hours, your phone number and a map, and it gets a steady trickle of visitors that never spikes, you will likely never come within sight of a concurrency ceiling. For that site, the cheapest shared plan is genuinely fine, and paying for serious infrastructure would be paying for headroom you will never use.

The ceiling only bites when two things are true at once: your traffic is uneven, and the busy moments matter commercially. A shop running a launch. A restaurant taking bookings after a feature. Any business whose best day is also its most valuable. WordPress now runs somewhere around 43 per cent of the web, give or take depending on whose count you read, and a large slice of those sites are exactly that kind of business, sitting on hosting that was only ever specified for the quiet Tuesdays.

Conclusion

The brewery's site was never broken. It did precisely what its hosting was built to do: protect a shared server by refusing traffic past a fixed line. The problem was that the line was set for an average day, and the whole point of the release was to have an extraordinary one.

That is the real lesson hiding inside a 503 error. Hosting is not just where your website sits. It is the decision, made long before your busy day arrives, about whether that day gets served or turned away. If your site has ever stumbled at the exact moment it should have been cashing in, it is worth knowing the ceiling was there all along, and that it did not have to be.

Sources