Affiliate disclosure: Some links on this page are affiliate links. I earn a commission if you buy through them, at no extra cost to you. I only point at services I've actually run client sites on.

The 8pm Email — One Number, Three Different Crashes

Three Slack messages hit me in the same week last March. All three from clients I'd helped scale past 50K the previous year. All three opened with some variant of the same five words: "we crossed 100K and broke." The stories underneath were nothing alike.

The first was a productivity blog on SiteGround GrowBig. Their analytics had been climbing toward 100K for months, the host's marketing copy literally said the plan was "designed for around 100,000 monthly visitors," so they figured they had headroom. Then the 8pm US-Eastern reading window started returning 504 Gateway Timeout — but only between 8pm and 11pm, only on logged-in pages, and only on weekdays. Off-peak the site was fine.

The second was a small course-hub on WP Engine Growth at $109/month. Pages stayed up. The "crash" arrived as an invoice line item: a $188 overage charge on top of the Growth tier, with an email suggesting they upgrade to Scale at $276/month. Their Google Analytics 4 dashboard showed 96,400 sessions for the month — under the 100K cap by every metric they could see.

The third was a WooCommerce store the previous owner had moved from Bluehost to a self-managed DigitalOcean 4GB droplet at $24/month. Page loads were great for two weeks. Then on the morning of a Klaviyo email blast, MySQL hung. The cart endpoint stopped responding. I remember opening top, watching mysqld pin all four cores in a steady red bar, and feeling that specific drop in my stomach when I noticed the absence of any redis process at all — the previous owner had treated migration like a file copy and forgotten that a tuned WordPress server is half stack and half tuning. The next ninety minutes vanished into config files. The droplet had room. The configuration didn't.

Same number — 100,000 monthly visitors — three completely different failure modes. None of them are what the SERP recommendation lists prepare you for.

I've spent the last two years watching the same pattern repeat. Someone's blog or store grows past 100K, they search "best hosting for 100K visitors," they get a list that lines up Bluehost Business next to WP Engine Growth next to a Kinsta plan next to Cloudways and tells them to "upgrade to the next tier." The advice is wrong because the question is wrong. There isn't a next tier at 100K. There are three crashes happening at the same flow rate, and which one bites you depends on what kind of site you run.

One WebHostingTalk thread put the paradox cleanly: "Most half decent shared hosting plans are more than capable of dealing with 100,000 visitors per month, though the main issue seems like it could be resource related." That's it in one sentence. The plans can serve 100K visits. They can't always serve your 100K visits, because the server doesn't see 100,000 visits — it sees concurrency.

Why "100K Monthly Visitors" Is Three Different Loads

A month has roughly 2.6 million seconds. 100,000 visits sound dramatic; spread across that timeline they average about 0.04 requests per second. Servers don't fall over at 0.04 req/s. They fall over at the peak — which depends entirely on your traffic shape and what each request actually does.

Here's the three-question test I run with every client before recommending a plan. Score yourself honestly:

Question 1 — Dynamic ratio. Of every 100 page views, how many can a static cache serve? A read-mostly blog with no membership wall sits around 90-95% cacheable. A SaaS dashboard or members-only course sits at 5-10% — the personalized UI defeats the cache. WooCommerce sits in between for catalog pages, but the cart and checkout endpoints are 0%.

Question 2 — Logged-in concurrency. At your peak fifteen-minute window, how many users are signed in at once? A blog rarely has any. A membership site might have 30-50 simultaneous logged-in members. An LMS during a course launch can hit triple that.

Question 3 — Database write frequency. Per minute at peak, how many writes hit the database? Page views = zero writes (cached) or one read (uncached). A WooCommerce add-to-cart fires several writes. A checkout fires dozens. A "save progress" button on a quiz plugin fires one per click.

Score those three and you fall into one of three load classes:

• Class A — Cache-friendly content site. Blogs, news sites, marketing pages. 90%+ cacheable, near-zero logged-in users, almost no writes. 100K visits/month means a peak of maybe 5-10 concurrent uncached requests.
• Class B — Logged-in dashboard or membership site. SaaS apps, course platforms, paid newsletters, member portals. 10-30% cacheable, 30-80 concurrent logged-in users at peak, a steady trickle of writes (progress, sessions, comments). 100K visits means 30-50 concurrent dynamic page renders at peak.
• Class C — Transactional store. WooCommerce, EDD, Shopify alternatives, any cart-driven flow. 60% cacheable on catalog, 0% on cart/checkout, write-heavy on every cart event. 100K visits means maybe 10-20 concurrent users but each session is hitting the database hard, especially during sale spikes.

The SERP doesn't ask you any of this. The SERP gives you a numbered list. That's why the SERP gets it wrong — Class A, B, and C all hit a wall at exactly 100K, but they hit three different walls.

Crash Type 1 — The PHP Worker Cliff (Shared and Lower Managed Tiers)

Every shared-hosting plan that says "supports 100,000 visitors" is making a bandwidth argument, not a concurrency argument. The number you actually need to know is the PHP worker count — the number of simultaneous dynamic requests the server will process at the same time. Once you exceed that, requests don't slow down gracefully. They queue, and once the queue fills, the load balancer throws away the oldest entries and returns 504.

Servebolt's engineering team explained the dynamic in one sentence I now quote at every onboarding call: "Once you've reached the limit of your available PHP workers, the line starts to push out older requests which may result in 504 errors or fragmented requests." Not "the site gets slower." Older requests get evicted. That's why the SiteGround client's site went from "fine" to "504s every night between 8 and 11pm" with no transition phase — the 8pm reading peak put logged-in members beyond the worker count and the queue collapsed.

Public worker counts are spotty by design — most shared hosts don't publish them. Here's what I've been able to confirm or test:

SiteGround's own published 4-worker number is the most useful data point in that table because everyone else hides it. Four workers is fine for Class A — your CDN absorbs 90% of traffic, only ~10 origin requests reach PHP per minute at peak, the workers cycle through them in milliseconds. For Class B at 30+ logged-in concurrent users, four workers is a guaranteed queue. The math is unforgiving and the marketing copy doesn't help.

The CPU quota story is the second half of the same problem. A separate issue I've seen repeatedly on SiteGround is documented in their own user community: "Adding traffic of approximately 100 visitors per day to a SiteGround site made the site nearly unusable as it times out due to CPU usage." CPU minutes get consumed even faster on logged-in pages, and the throttle kicks in well below the marketed visitor cap. The plan is sized for cacheable static traffic. The bill is sized for cacheable static traffic. The CPU governor doesn't care what tier you're on.

If you're Class A and you have a competent CDN in front, GrowBig at the renewal price of $29.99/month genuinely works for 100K. If you're Class B or C, you're already on borrowed time at this tier — the question isn't whether to upgrade, it's which direction.

Crash Type 2 — The Visitor-Counting Tax (Managed WordPress)

The natural next step from "shared can't handle my logged-in users" is managed WordPress. WP Engine Growth gives you 100K visits for $109/month. Kinsta has a 100K-cap plan. Pressable's Signature 3 covers 75K and Signature 5 jumps to 400K. The promise is "we tune the stack so you don't have to." The trap, especially on WP Engine, is that their 100K and your 100K are not the same number.

Here's the line item every WP Engine customer eventually learns the hard way: their billable visit is counted as unique IP per day, deduplicated on a 24-hour cookie window. Google Analytics 4 counts user-based sessions. Those two definitions diverge in predictable ways. As one analysis of the metric mismatch put it: "WP Engine counts visitors differently than Google Analytics: measuring unique IP addresses per day rather than sessions, which typically produces counts 20-50% higher than third-party analytics tools." 20-50% higher. On the same site. With the same traffic.

The community fallout is loud and consistent. One thread documented it bluntly: "Every other month I am getting an email about some overage and then needing to upgrade to a plan that is 2-3x my current one." If you've ever wondered why managed WP review sites keep mentioning bill shock as the #1 complaint, this is the mechanism.

Let me put concrete numbers on it. Suppose your GA4 shows exactly 100,000 sessions for the month. A few realistic things happen on the WP Engine side:

• Bot traffic that GA4 filters but WP Engine doesn't always (some bots spoof user-agents that pass GA's filter but still come from datacenter IPs that hit the site). Realistic inflation: 10-20%.
• Mobile carrier IP rotation. The same human reading your blog over five days from their phone may show as 5-10 unique IPs over the month. GA4 sees one user; WP Engine sees several billable visits. Inflation: 10-25%.
• Returning users on shifting home IPs — anyone with dynamic ISP allocation effectively reads as a fresh visitor every other week. Inflation: 5-15%.

Stack those and your GA4 100K typically comes out somewhere between 130,000 and 200,000 billable visits on WP Engine. At their published $2 per 1,000 excess, that's:

• Best case (130K billable): 30,000 over × $2/1,000 = $60/month overage on top of $109 → $169 effective monthly.
• Typical (160K billable): 60,000 over × $2/1,000 = $120/month overage → $229 effective.
• Bot-heavy (200K billable): 100,000 over × $2/1,000 = $200/month overage → $309 effective.

The Trustpilot/BBB pattern of "$188 overage on a $250 plan despite GA showing traffic within limits" is exactly this math, just with a year of compounding. And the overage is billed in arrears, monthly — so you only see it after the fact, and it can fluctuate enough that two consecutive months at "under 100K GA" can produce wildly different bills.

Kinsta plays the same game more transparently. Their tier ladder for 2026 is more honest about what each price gets you:

Two things stand out. First, "Kinsta starts at $29" is technically true and practically misleading — Starter caps at 35K, so a 100K site has to climb to the WP 5 tier at roughly $115/month. The price-curve from "Kinsta entry point" to "Kinsta at 100K" is more than 3x what the homepage suggests.

Second, Kinsta's $0.50 per 1,000 overage is one-quarter the price of WP Engine's $2 per 1,000. If you're going to overshoot anyway, the overage rate matters more than the headline price. A 30K monthly excess costs you $15 on Kinsta and $60 on WP Engine. Twelve months of that is the difference between $180 and $720.

Pressable is the quiet contrarian here. Signature 3 covers 75K visits at $50/month with no per-visit overage — they treat the visit number as a soft sizing guideline, not a billing meter, and bump you to a higher plan only if you're consistently over for several months. For a Class B site that lives in the 75K-120K range, Pressable's pricing is the easiest to predict because there's no inflation multiplier hiding in the definition of "visit."

If you're choosing managed WordPress, the question isn't "who is cheapest at 100K" — it's "whose overage rate hurts least when I overshoot, and how is their visit defined." That's a different question than the SERP asks.

Crash Type 3 — The Configuration Cliff (Self-Managed VPS)

The third path is the one that looks like it solves everything on paper. A DigitalOcean Basic 4GB droplet runs $24/month for 2 vCPU, 4GB RAM, 80GB SSD, and 4TB of transfer. No visit cap, no overage, no PHP worker artificial ceiling — you set the workers yourself. Vultr's Cloud Compute Regular 4GB matches at $24/month with NVMe instead of SSD. Linode's 4GB plan is identical at $24. And then the European cost-optimized side gets weird: Hetzner's CX33 is 4 vCPU, 8GB RAM, 80GB SSD, 20TB transfer for €8.49/month, about $9.99 — that's twice the resources at roughly 40% of the price. Contabo's Cloud VPS 6 sits in the same range at $4.95 for 4 vCPU and 8GB on 12-month prepay.

So you spin up a 4GB droplet, install LAMP via the marketplace one-click, point your domain, restore the WordPress backup, and watch the page-load metric drop from 2.4 seconds to 700ms. Beautiful. Then a week later the database hangs and you're paged at 6am.

The default LAMP stack on a 4GB droplet is sized like it expects to run a tutorial site. It comes with Apache's default prefork settings, no opcode cache beyond the bare PHP defaults, no object cache, no query cache, and a MySQL configuration where innodb_buffer_pool_size is set to 128MB regardless of how much RAM you actually have. You can run any benchmark you want on this stack and it will look good with one user. With 30 logged-in concurrent and a couple of cart events per minute, every request will hit the database, MySQL will fall back to disk reads on most queries, and the whole stack will lock up under what was supposed to be a comfortable load.

This is the failure mode the WooCommerce client hit. I've watched it happen on three different VPS providers with three different operators, all of whom did everything right except install the four pieces of software that turn a generic Linux box into a WordPress server. Here is the minimum stack — call it the four-piece checklist:

1. Nginx with FastCGI cache (or LiteSpeed/OpenLiteSpeed). Apache's prefork model spawns a process per request and doesn't share memory the way Nginx does. On 4GB RAM, you want every spare megabyte going to MySQL and PHP, not to redundant Apache children. Skip this and you'll waste roughly 30% of your RAM on web-server overhead.
2. PHP-FPM with a tuned worker pool. On 4GB total, 6-8 PHP-FPM workers is the realistic ceiling — each WordPress worker eats roughly 80-150MB depending on plugins. Skip the tuning and the default pool of 5 dynamic workers either undershoots and queues, or overshoots and OOMs the box. Either way it crashes.
3. Redis as object cache (via the official Redis Object Cache plugin). WordPress's native object cache is per-request — every page rebuilds it from scratch. Redis lets multiple requests share the cache and keeps frequently-accessed options, transients, and user metadata in RAM instead of slamming the database. For Class B and C sites this is the single highest-leverage change. Skip it and your database becomes the bottleneck before you even cross 50K visits.
4. Cloudflare (or Bunny) in front, with full page cache for anonymous traffic. Even a perfect origin still gets crushed if you put all 100K monthly visits through it. The CDN is what makes 4GB of RAM enough — it absorbs the cacheable 60-90% before requests reach origin. Skip it and your worker tuning won't matter.

You can do this. It's a Sunday afternoon project for someone who's comfortable with Linux command-line and has done a server migration before. It is absolutely not "set it and forget it" — you'll spend 2-4 hours per quarter on updates, log review, and the occasional security patch. Across a year, that's call it 12-16 hours of operations work you wouldn't be doing on a managed plan.

The configuration cliff isn't a reason to avoid VPS. It's the reason VPS is cheaper. You're trading $50-90/month worth of operations work for $24/month of infrastructure cost. If your hourly rate (or your patience) makes that math work, the VPS path is the most flexible by far. If it doesn't, the saving is illusory — the first time you spend a Saturday night fixing a hung MySQL process, you've eaten the $80 you saved.

The Verdict — Three Roads, Three Cost Curves

Run yourself through the three-question test from earlier. Then pick a road.

If you're Class A — cacheable content site, blog, news, marketing pages. Self-managed Hetzner CX33 (€8.49) or Contabo Cloud VPS 6 ($9.00) plus Cloudflare's free tier plus the four-piece stack. Total infrastructure: under $10/month. With 12 hours/year of ops work this is the cheapest path that handles 100K cleanly. Add roughly $20/year for an off-site backup target. Twelve-month TCO: $80-130 infrastructure plus your own time.

If you're allergic to Linux but you're still Class A, SiteGround GrowBig at $29.99 renewal works — but only with Cloudflare in front and the SG Optimizer plugin set aggressively. You'll be using the worker count you have, not the worker count the marketing implies. Twelve-month TCO: $360 renewal, and you're managing your own backups.

If you're Class B — logged-in dashboard, membership site, course platform. This is the tier where the visitor-counting tax bites hardest, because logged-in pages don't cache and your bot traffic still counts on WP Engine. Pressable Signature 3 at $50/month ($600/year) handles 75K visits cleanly with the soft-cap pricing model. If you're consistently above 100K, Signature 5 jumps to $129.17/month ($1,550/year) and gives you 400K of headroom. Twelve-month TCO: $600-1,550.

If you'd rather run your own stack and you have the operator skills, a Hetzner CX33 (4 vCPU, 8GB RAM at €8.49/month, about $9.99, EU-only, about $9.99) or DO Basic 8GB at $48 with the four-piece stack will outperform Pressable Signature 3 on every benchmark for a fraction of the cost — but you own the on-call. Twelve-month TCO: $72-576 infrastructure.

If you're Class C — WooCommerce, transactional, cart-heavy. This is where the price curve gets steep because the database load is the bottleneck and you can't cache it away. Two paths:

• Managed: Kinsta WP 5 visits plan at ~$115/month. Includes their tuned MySQL, Edge Caching, and a transparent overage at $0.50/1,000. Twelve months: $1,380. WP Engine Growth at $109 sounds cheaper but the $2/1,000 overage on bot-inflated billable counts will reliably push the actual annual to $1,800-2,500. The headline gap closes once you account for inflation.
• Self-managed: DigitalOcean Basic 8GB at $48/month or Vultr equivalent, with the four-piece stack plus a properly tuned innodb_buffer_pool_size at 25-30% of RAM. Twelve months: $576 infrastructure. You will spend real time on this — budget 20-30 hours per year. For a store doing $10K+ MRR the time math is fine; for a store doing $2K MRR the managed path is worth it.

The "best" plan at 100K isn't a brand. It's a load class. If someone tells you that the answer to 100K visitors is the next tier of whatever you're already on, ask them which crash mode they're solving for. If they don't have an answer, the recommendation is decorative.

One last honest line before the framework: if your traffic is climbing steadily toward 100K but you haven't actually seen 504s during peak hours, slow logged-in pages, or unexplained overage emails, none of these recommendations are urgent. The cheapest move is the one you don't have to make this quarter. Wait for the actual symptom — pre-emptive upgrades at this tier almost always over-buy.

Three situations where this framework doesn't apply. Be honest with yourself before acting on any of the recommendations above:

• You have spike traffic, not steady-state 100K. If your traffic is normally 20K and a single PR launch sends 100K in a 48-hour window, you don't need any plan in this article — you need an auto-scaling architecture (often serverless or a static-export front end behind a CDN). The TCO math here all assumes steady-state 100K.
• You're running an API or SaaS backend, not a website. If each "visit" triggers multiple database writes inside your application (a per-call analytics platform, a user-state-heavy SaaS dashboard), the bottleneck is the database itself, not the hosting tier. Throwing a managed-WP plan at it will not help — the right move is splitting the database to a managed Postgres or MySQL instance with its own resource budget.
• You're under 50K and reading this defensively. If you've landed here because you're worried about scaling and you haven't crossed 50K yet, the bottleneck is almost certainly a plugin, a theme, or the absence of a page cache. Spend a Saturday on Query Monitor and a real caching plugin before you pay anyone for a bigger plan. You probably don't need the next tier yet.

FAQ

My GA4 shows 100K — should I trust WP Engine's billable visit count?

No. Their count is built on a different definition (unique IP per day, 24-hour deduplication) and runs 20-50% higher than session-based analytics on most sites. Before signing up, ask them to estimate billable visits from a 7-day server log import. If you're already on Growth and the bills are climbing, log into the User Portal, find the Visits report, and compare it to GA4 sessions for the same window. The ratio is your inflation multiplier — multiply your future GA4 number by it to estimate real bills. Most sites I've seen settle between 1.3x and 1.7x.

Can SiteGround GrowBig actually handle 100K visits with WooCommerce?

For a small-catalog store with mostly browsing traffic and a CDN in front, yes — but you're sizing the plan for the cache-hit path, not the checkout path. The 4 PHP workers will queue under any meaningful concurrent checkout load. If your peak concurrent cart sessions ever exceed 15-20, the 504 wall is real. The CPU quota will hit you first on plugin-heavy stores (any popular cart abandonment, search, or recommendation plugin makes uncached requests expensive). Move to GoGeek if you want to stay in shared, or jump to managed WP — don't try to make GrowBig stretch.

Is a managed VPS provider like Cloudways worth the markup over going direct to DigitalOcean?

Cloudways' DO 4GB managed sits roughly $14-18 above going direct, depending on which add-ons you toggle (their pricing has been re-tiered twice in the last eighteen months — pull the current quote from their site before committing, don't trust any review article on the dollar number, this one included). Conceptually, the markup buys you a tuned stack (Nginx + Varnish + Redis preconfigured), a control panel for backups and SSH key management, and a support tier that knows the WordPress side. Decision rule I use with clients: if you've never tuned innodb_buffer_pool_size by hand and don't want to learn this quarter, the markup pays for itself before the third invoice. If you've stood up the four-piece stack at least three times before and can do it on a Sunday afternoon, the markup is pure tax — go direct, save the $200/year, and put it toward an off-site backup. The break-even point isn't dollars; it's whether the four-piece stack feels like a project or a chore.

How do I know if I'm hitting the PHP worker limit before the 504s start?

Three signals, all visible in your logs before users see errors. First, response times start to bimodal — most requests stay normal but a small percentage spike to 5-30 seconds (those are the queued ones). Second, error logs start showing upstream timed out or FastCGI sent in stderr: "Primary script unknown" entries during peak windows. Third, if your host gives you any kind of resource graph, watch for "Active PHP processes" hitting a flat ceiling at peak — that ceiling is your worker count and you're queueing above it. New Relic or a $9/month Blackfire account will show this without asking the host. Don't wait for the 504s to file the upgrade ticket.

If I add Cloudflare and a page cache, can shared hosting survive 100K?

For Class A, yes — and the gap closes dramatically. A 90% cache hit rate turns 100K visits into 10K origin requests per month, which any decent shared plan handles. The catch is that the 10% that misses cache tends to be the most expensive 10% (logged-in pages, search results, dynamic personalization). For Class B and C, the cache covers the cheap pages and leaves the expensive ones for the origin to handle alone, which is the worst possible split. Cloudflare in front of GrowBig saves a Class A site. It does not save a membership site or a WooCommerce store.

What's the real difference between Kinsta Starter at 35K and WP 5 at 100K?

Roughly $86/month on the headline — Starter at $29.17 annual versus WP 5 at ~$115. But the cost math is counterintuitive. At Kinsta's $0.50/1,000 overage rate, a 100K-visit site on Starter would pay $29.17 + (65 × $0.50) = $61.67/month, which is still $53/month cheaper than WP 5. On pure cost-per-visit, Starter plus overage stays the cheaper line indefinitely. What you actually buy with WP 5 is four extra WordPress installs and a meaningfully larger server container (more CPU and RAM in the underlying isolated environment, which translates to faster TTFB on logged-in pages). For a single Class A blog, Starter+overage is the rational pick. For a Class B/C site that needs the container performance, or anyone running multiple sites, WP 5 earns its premium — but not because of the visit cap.

Closing

The three messages I opened this article with all eventually got to a working setup. The blog stayed on SiteGround but added Cloudflare and stopped trying to serve logged-in members through a 4-worker pool. The course-hub moved off WP Engine to Pressable Signature 5 and stopped getting overage emails. The WooCommerce store stayed on DigitalOcean but I spent a Sunday installing the four-piece stack and tuning innodb_buffer_pool_size from 128MB to 1.2GB — same droplet, same price, no more midnight pages.

None of those answers came out of the same plan. None of them came out of "upgrade to the next tier." Each came from naming the actual crash mode first and then picking the cheapest tool that solved it. The hosting market spends a lot of energy convincing you that 100K visitors is one problem with one product behind it. It's three problems with three different prices, and you only need to solve the one that's about to bite you.