The wp-admin/admin-ajax.php response time on a Hostinger Business plan tells you almost everything you need to know about a WooCommerce store before the merchant opens a support ticket. Sitting around 180–350ms under light load, fine. Crawling to 1.8s once forty-odd concurrent sessions are on the checkout, with cart fragment refreshes queueing behind each other — not fine, and the giveaway is that it is bursty: most requests still come back quickly, a handful stall to 4–6 seconds, and the failures cluster on the requests that mattered (the ones with an active cart). Two years back, forty concurrent checkouts was a number almost nobody we worked with hit. Now a mid-sized D2C brand running one decent Meta campaign during a sale window will touch that in the first hour and not come down for the rest of the evening — and that shift is most of why we changed the recommendation. Hostinger's plan didn't really get worse. The shape of the traffic did.
Why we used to recommend Hostinger for almost every Woo build
For a long stretch — 2021 through most of 2023 — Hostinger Business was the default answer when a client asked us where to host their WooCommerce store. The math was hard to argue with. ₹299/month on the promotional tier, ₹699/month at renewal, LiteSpeed server, free SSL, a panel that didn't make non-technical founders cry. For a catalogue Woo store doing twelve to fifteen orders a day on manual fulfillment, it ran fine — genuinely, for that workload. We had builds on that plan that went two full years without us touching the server-side config.
And to be clear — we still recommend it, just not for the same client profile. A pure catalogue Woo with manual order processing, under about ₹20L annual GMV, two or three orders an hour at peak: Hostinger Business is still the answer. Migrating that kind of store to a managed VPS is a waste of the client's money and a waste of our time. The plan does what it advertises. The trouble starts further up the curve, and we were slow to spot where the curve bent.
LiteSpeed Cache is part of what made us slow. With LSCache turned on and ESI configured reasonably, you get a long honeymoon — three months, six months sometimes — where the cached HTML masks the underlying I/O contention. Anonymous traffic gets served from cache, the dashboard feels snappy, the homepage scores well on PageSpeed. The cache hides the symptom right until the cart-and-checkout flow (which is uncacheable by definition) starts taking the full brunt of whatever PHP workers are actually available. We have walked into more than one debugging session where the founder swore the site had been "fast for months" and then suddenly wasn't. It wasn't sudden. The traffic shape changed, the cacheable proportion dropped, and the floor under checkout finally became visible.
What the November post-mortem actually showed
9 November last year. A client running a skincare D2C brand on Hostinger Business, pushing a Diwali campaign that had been planned for weeks — Meta spend ramped up the previous Sunday, a couple of creators posting through the week, the usual shape. Razorpay webhooks started timing out around 7:40pm. Orders were getting captured at the gateway but the order_status_completed hook wasn't firing on the WooCommerce side, so the store was sitting on a queue of "pending payment" orders that had actually been paid. The founder thought Razorpay was down. Razorpay's status page said otherwise. By the time they pinged us it was close to 9pm and the support thread was already six messages deep with the gateway's team.
Arjun ran the post-mortem the next morning. Access logs showed the pattern clearly enough once you knew what to look for: a long tail of admin-ajax.php requests stacked up between 7:30 and 8:15, response times degrading from sub-second to 8–12 seconds, and then a cluster of 504s on the Razorpay webhook endpoint right in the middle of that window. The webhook wasn't slow on Razorpay's side — it was slow getting processed because there were no PHP workers free to handle it. The cart fragment refreshes from concurrent checkout sessions were eating the worker pool, and the webhook was queued behind them. Razorpay retries, of course, but by the third or fourth retry the customer has already refreshed the thank-you page twice and emailed the founder.
The wp-admin sluggishness was the next thing we noticed in the same logs, and it had been there for weeks before the incident — we just hadn't been looking. Editing a product, saving a coupon, anything that takes a write lock on wp_options or wp_posts stalls during the same windows. Not crashes, just stalls. Founders learn to "do admin work in the morning" without quite knowing why. And once we started pulling logs from other clients in the same GMV band, the gateway-agnostic version of the pattern showed up too: webhook latency from any gateway starts drifting upward, and if the store has more than two or three active payment methods (Razorpay + Cashfree + COD + maybe a BNPL provider), each one's webhook is competing for the same worker pool, and the failure rate compounds.
The undocumented bit — and Hostinger will not tell you this in writing — is that the effective PHP worker ceiling on the Business plan sits somewhere around 35–45, depending on which node you land on. It is not advertised as a number. There is no panel setting that shows you. You infer it from behaviour: requests start queueing instead of executing once concurrent PHP-handling sessions cross that count, and admin-ajax.php is unusually expensive because WooCommerce uses it for cart fragment refreshes on every page load that contains a mini-cart widget. So a single visitor browsing four product pages with a populated cart is firing four admin-ajax.php calls, each holding a worker for 200–800ms. Forty concurrent visitors of that shape and you are at the ceiling without anyone having clicked "checkout" yet.
Riya argued with us internally about the threshold for a while — she thinks ₹50L is too high, that the symptoms start showing up nearer ₹35–40L for stores with a heavy mobile-traffic mix. She is probably right and we are still working out the right number. The rule we use now: migrate if any one of these holds — annual GMV around ₹50L and rising, sustained 30+ concurrent sessions during campaign windows, or more than three active payment methods running webhooks. GMV is a proxy, not a cause; the real cause is concurrent worker-holding requests, and GMV correlates with that loosely enough to be useful.
Where we move clients now, and what it actually costs
Cloudways on a DigitalOcean 2GB droplet, most often. ₹2,400/month-ish, give or take depending on the rupee and which add-ons the client wants. That gets you a real per-tenant PHP-FPM pool you can size, MySQL on the same droplet without the shared-I/O lottery, and Redis if you want object caching done properly. Migration time is usually a weekend if the store doesn't have anything weird going on, longer if there's a custom checkout or a half-broken multi-currency setup.
The three-year landed cost is where the conversation gets interesting. Hostinger Business at ₹699/month renewal works out to roughly ₹25,000 over three years. Cloudways DO 2GB at ₹2,400/month is closer to ₹86,000 over the same period. Difference of about ₹60,000. That sounds like a lot until you cost out one Diwali incident — the November post-mortem alone was 14 billable hours from us plus the founder's evening plus whatever the actual revenue impact of the stuck orders was (we never got a clean number on that; the client estimated somewhere between ₹1.8L and ₹2.4L in delayed-or-abandoned orders, which is a wide band and we don't entirely trust either end of it). One incident roughly pays for the upgrade two or three times over — depending on whose revenue estimate you believe.
We should be honest about Cloudways too. The DigitalOcean acquisition closed in 2022, and then around July 2024 there was a pricing restructure and some platform changes that we are still not thrilled about — the support quality dipped for a stretch, a few of the cheaper plans got reshuffled, and the panel grew some features nobody asked for. It is still the recommendation, but it is a less obvious recommendation than it was in 2022. We have looked at RunCloud + a bare DO droplet for a few of the more technical clients, and at Rocket.net for the ones whose budgets stretch. For a non-technical founder who needs a panel and a support chat that picks up at 11pm, Cloudways is still where we land — slightly grudgingly now, where two years back it was without hesitation.
One thing we do not do is move clients to Kinsta or WP Engine for stores in this GMV band. The pricing math doesn't work for Indian D2C margins. Maybe at ₹3Cr+ GMV, with international traffic and a real ops team, that conversation opens up. Not before. (We had this debate again last month with a client whose CFO was convinced Kinsta would "solve everything" — it would have, and it would also have eaten 4% of their net margin. Different post.)
The confession part. We still don't have a clean signal for when a catalogue-heavy store with low order volume but rising traffic crosses the threshold without a GMV spike to flag it. Sometimes we have migrated clients too early and the new infrastructure sat half-idle for nine months. Sometimes too late, and the client lost a campaign weekend to it — the November incident was too late by about six weeks, in retrospect; the warning signs were there in late September and we filed them under "watch this". What we are doing now is monitoring admin-ajax.php P95 latency more than GMV — if P95 starts drifting past 1.2s during the busiest hour of the day on three consecutive weekdays, that is the signal to start the migration conversation, not the revenue dashboard. The exact number we are still calibrating. Ask us again in six months and it may have moved.
