Across one 23-day period in May 2026, an LR Luxe Competitions site running on Performance Hosting processed 4,556 orders for 25,367 individual tickets, generating £28,580.72 in net sales, with 26 percent of that revenue concentrated in a single TikTok Live draw night (£7,463.57 on 21 May). The Performance Hosting dashboard recorded 650,530 HTTP requests in seven days, peaks of 22,173 requests in a single hour, 19.66 percent of PHP requests served by burst capacity above the dedicated baseline, and a 96.4 percent 200 OK rate across 647,000 edge responses.

This guide covers the WooCommerce hosting requirements that make numbers like these possible, the failure patterns that show up when standard managed WordPress hosting is used for competition workloads, and the specific technical configuration UK competition operators need to look for when choosing a hosting provider.

We have built and host over 50 UK competition websites at the time of writing. The data in this guide is drawn from the hosting analytics, load testing, and operational patterns we see across that portfolio. The numbers are not theoretical. They are what UK competition operators running real instant win competitions, TikTok Live draws, and weekly prize draws are pushing through their infrastructure right now.

Why WooCommerce hosting for competition websites is different

WooCommerce is the underlying ecommerce engine for most UK competition websites because it gives operators the flexibility to build custom ticket logic, free entry routes, skill question gating, instant win mechanics, and bundle pricing on top of a stable transactional foundation. The platform is not the issue. The hosting layer beneath it is.

Three structural differences set competition WooCommerce sites apart from standard WooCommerce ecommerce:

Traffic is not steady-state. A standard ecommerce store has gradual traffic curves. A competition website has scheduled spikes. Entry volume concentrates in the final 30 to 90 minutes before draw close. Instant win competitions and TikTok Live draws produce even sharper spikes. Across the LR Luxe data referenced above, 26 percent of one month’s revenue arrived on a single TikTok Live night. Hosting sized for the monthly average will fail on draw nights.

Each order generates multiple sequential database writes. A standard order generates one or two database inserts. A competition order generates one insert per ticket purchased. Across the LR Luxe data, the average order contained 5.57 tickets, which means every checkout produces six sequential ticket-row inserts inside a single order transaction. Multiply this by concurrent buyers during peak windows and the database write queue becomes the system’s bottleneck.

Post-order integrations are heavy. Competition operators typically run marketing automation (Klaviyo, Omnisend, ActiveCampaign), loyalty platforms (TeraWallet, cashback), email delivery (Mailgun, SendGrid via FluentSMTP), and SMS automation. If any of these integrations fire synchronously during checkout rather than asynchronously after, they extend checkout response times under load.

These three factors compound. A £1 ticket competition with a 5,000-ticket cap, sold in bundles of 25 or 100, with Klaviyo and Omnisend both firing on checkout, on standard managed WordPress hosting, will produce the exact failure patterns we see most often: 500 errors, 429 rate-limited responses, timeouts at the place-order step, and entries that never reach the database despite the customer’s card being charged.

The reasons payment providers reject competition websites and the biggest mistakes new competition businesses make cover the wider commercial consequences of these failure patterns. This guide focuses on the WooCommerce hosting specifications that prevent them from happening in the first place.

What 7 days of competition draw traffic actually looks like

The Performance Hosting analytics dashboard for the LR Luxe site over a recent 7-day window shows the following:

Metric	7-day value	Week-on-week change
Total HTTP requests	650,530	+351.98%
Bandwidth	23.52 GB	+427.47%
Page views	23,683	+318.04%
Visits	4,213	+392.63%
Peak single-hour requests	22,173	n/a

The week-on-week change figures matter as much as the absolute values. Competition traffic does not just spike within a 24-hour window; it spikes across weeks too, as operators schedule larger prize draws, larger marketing pushes, or recurring TikTok Live nights. The hosting infrastructure needs to absorb both the within-day spike and the week-on-week growth without manual intervention from the operator.

In the same 7-day window, the WooCommerce admin recorded:

Metric	Value
Net sales	£28,580.72 (23-day month-to-date)
Orders	4,556
Products sold (tickets)	25,367
Average order value	£6.27
Average tickets per order	5.57
Single-day peak revenue	£7,463.57 (21 May, single TikTok Live night)
Visitor-to-order ratio	1.31 orders per visitor

The 1.31 orders-per-visitor figure is worth flagging: it means many visitors are placing more than one order in a session, which is the repeat-entry pattern that drives long-term competition revenue. This is only possible if the hosting infrastructure delivers a fast, reliable checkout on every attempt. A 7-second checkout drops repeat orders. A 1-second checkout protects them.

PHP worker requirements for competition WooCommerce hosting

PHP workers are the unit of concurrency on a WordPress site. Each concurrent request consumes one worker until it completes. When all workers are busy, additional requests queue or fail. The right worker count for a competition WooCommerce site depends on peak concurrency, not average traffic.

For the LR Luxe site in the 7-day window referenced above, the worker profile was:

Worker metric	Value
Average PHP workers in use	2.22
Minimum PHP workers in use	1.00
Average peak PHP workers in use	9.21
Single observed peak PHP workers	28
Assigned CPU cores	10

The single observed peak of 28 workers running against an assigned 10 CPU cores would be impossible on hosting without burst capacity. Burst capacity is hosting resource that sits available above the dedicated baseline allocation, ready to absorb spikes without triggering a slow reactive autoscale event. The 19.66 percent burst figure across the same period confirms that almost one in five PHP requests during the week was served by capacity above the baseline; without that burst layer in the configuration, those requests would have queued or failed.

For UK competition operators evaluating WooCommerce hosting, the right question is not “how many workers do I get?” but “what is the relationship between baseline workers, burst capacity, and the platform’s response time when burst is engaged?” Hosting that advertises high worker counts but cannot burst above them during instant win windows will fail during the moments that matter most.

A practical starting framework, drawn from the configurations we see working across UK competition operators:

• Small operator (under 500 entries per draw, weekly close): Baseline 4 to 6 PHP workers, burst headroom available above. Total monthly hosting cost broadly aligned with the £99 entry-level performance hosting tier.
• Mid-size operator (500 to 2,000 entries per draw, multiple weekly draws, occasional instant wins): Baseline 8 to 12 PHP workers, burst headroom for instant win windows, memory ceiling and database connection pool scaled alongside.
• High-volume operator (over 2,000 entries per draw, multiple daily instant wins, TikTok Live draws): Baseline 16 to 24 PHP workers, scheduled scaling around recurring draws, database read replicas, separate async worker pool for Action Scheduler jobs.

PHP request behaviour: normal, burst, and rate-limited

Beyond worker count, the breakdown of how individual PHP requests are served reveals whether the hosting configuration is working. The LR Luxe 7-day data:

Request category	Share	Meaning
Normal	72.87%	Served by dedicated baseline workers
Burst	19.66%	Served by burst capacity above baseline
Rate limited	7.47%	Refused by the platform’s rate-limiting layer

The 72/20/7 split tells a specific story. Roughly three quarters of traffic was served by baseline capacity, which is exactly what you want most of the time. One fifth required burst, which is exactly what burst capacity exists for. The 7.47 percent rate-limited figure represents requests refused by the platform, and this is where the commercial cost of hosting becomes visible.

A rate-limited PHP request typically translates to a customer seeing a slow page load, a timeout, or in checkout cases a failed order. Across 650K weekly requests, 7.47 percent is roughly 48,500 refused requests. Not all of those are checkouts; many are static page loads or repeat browsing. But every refused checkout request is a lost order or a customer who tried twice and gave up. For a high-volume competition operator, reducing the rate-limited share from 7 percent to 2 percent is a direct revenue uplift.

The fix is not always “buy more capacity.” It is often a combination of:

• Raising baseline worker count to reduce burst dependency
• Pre-scaling capacity ahead of known draw windows rather than relying on reactive autoscaling
• Tuning rate-limit thresholds for the application’s actual traffic profile
• Moving synchronous post-order integrations off the request path

The pricing-to-infrastructure connection covered in our raffle ticket pricing guide explains why low-priced bundled-ticket competitions produce the most rate-limited responses and how to size hosting for the resulting concurrency profile.

Edge status codes: what 429, 403, and 500 actually mean for competition operators

The same 7-day period produced the following edge status code distribution:

Status code	Count	What it indicates
200 OK	624,234 (96.4%)	Successful request
207 Multi-Status	6,924	Mixed-outcome response (typically API batched calls)
499 Client Closed Request	5,571	Customer’s browser cancelled the request mid-flight
302 Found	4,213	Redirect (often during checkout flow)
301 Moved Permanently	3,570	Permanent redirect
429 Too Many Requests	441	Rate limited at the edge
403 Forbidden	416	Blocked (security / WAF)
500 Internal Server Error	5	Application error

For competition operators reviewing hosting performance, the patterns worth watching:

• 429 Too Many Requests is rate limiting at the edge layer (Cloudflare, CDN, or WAF) rather than at the PHP worker layer. A spike in 429s during draw windows indicates the edge rate limits are tuned for steady-state traffic, not for competition spikes. The fix is bypassing edge rate limits for known dynamic routes or raising thresholds.
• 403 Forbidden spikes during draw windows often indicate a WAF or bot-protection layer mis-classifying real entrants as bots because the burst of requests looks anomalous. The fix is tuning the bot-protection layer to whitelist the checkout and entry routes.
• 499 Client Closed Request indicates the customer abandoned the request, usually because it was taking too long. A rising 499 rate is the strongest early warning of checkout-time problems, well before 500 errors appear.
• 500 Internal Server Error is an application-level failure (PHP crash, database connection exhausted, plugin conflict). Five errors across 650K requests is acceptable. Fifty would indicate a real problem.

Hosting built for competition draw concurrency

Specialist competition hosting with dedicated PHP workers, burst capacity, and pre-scheduled autoscaling. 50+ UK competition sites hosted. From £99/month.

See competition hosting →

Why standard managed WordPress hosting cannot handle competition draw load

Most managed WordPress hosting offered to UK operators (Kinsta, WP Engine, SiteGround, IONOS, GoDaddy Managed, and similar) is built for steady-traffic content sites, agency builds, and small ecommerce. The hosting is competent for those workloads. It is not built for competition draw concurrency.

The specific failures we see when competition operators launch on standard managed WordPress hosting:

Worker queue exhaustion within minutes. A draw closing at 8pm produces a concurrency spike at 7:59pm that consumes every worker in the pool. New entry attempts queue. Customers see slow page loads, then timeouts. Many close their browser, generating 499 status codes. The operator sees a drop in completed orders during what should be the highest-conversion 60 seconds of the week.

Database connection saturation. Each PHP worker consumes a database connection. Competition checkouts hold connections longer than standard ecommerce checkouts because of the sequential ticket-row inserts. Standard managed hosting database connection limits are sized for fewer workers and shorter connections. When the limit is hit, new database operations fail or queue.

Rate-limited admin operations. Operators trying to manage their site during a live competition (drawing winners, updating prize details, manually adjusting an order) often find admin routes rate-limited because the platform’s rate-limiting layer sees the simultaneous customer traffic and the admin traffic as a single source.

Plugin conflicts under load. Many WooCommerce plugins (marketing automation, cashback, loyalty, SMTP) work fine at low traffic and fail at high concurrency because they were designed and tested at single-user scale. We have load-tested staging environments where one specific plugin combination dropped order completion p95 from 4 seconds to 86 seconds purely because of synchronous third-party API calls firing during checkout.

The performance benchmark we hold our Performance Hosting tier to is a 0.4-second average page load and 99.9 percent uptime across the entire portfolio of competition sites we host. Those numbers are not aspirational targets. They are the threshold below which competition sites lose customer trust and entries.

WooCommerce-specific configuration for competition hosting

The hosting infrastructure is necessary but not sufficient. The application layer running on top of the hosting needs specific configuration as well. The two configurations that matter most:

Action Scheduler for asynchronous post-order processing. WooCommerce ships with Action Scheduler, a job queue that allows any post-order hook to fire as a scheduled background action rather than executing inline during checkout. Without it, every marketing platform integration, every email send, every cashback calculation, every Action Scheduler queue item, and every ticket-row insert blocks the checkout response until it completes. Properly implemented, Action Scheduler moves all of these off the synchronous path and the checkout completion time drops from tens of seconds back to one or two seconds. Every UK competition WooCommerce site at scale should have this in place before the first high-volume draw.

Cloudflare proxy mode disabled on dynamic routes. If the site sits behind Cloudflare, the orange-cloud proxy mode should be disabled on checkout, cart, account, and ticket allocation routes (DNS-only mode for those paths). Proxy mode interferes with CSRF tokens and session handling under concurrent load and introduces CSRF token mismatches during checkout spikes. Static asset routes (images, fonts, JavaScript, CSS) can stay on full proxy mode; dynamic routes should not.

The full feature set we build into every Nera competition WooCommerce platform is covered in the competition website features guide, which includes the platform-level features that pair with the hosting-level configuration described here.

How to evaluate WooCommerce hosting providers in the UK

Most UK WooCommerce hosting comparison content (Hosting Reviews, ProductReview, generic SaaS comparisons) is written for generic ecommerce buyers. The questions UK competition operators should ask are different. The evaluation checklist we use:

1. Does the provider guarantee dedicated PHP workers, or are workers shared across the platform? Shared workers cannot be reserved for your draw window. Dedicated workers can.
2. What is the burst capacity policy, and what does burst cost? A provider that advertises “unlimited bursting” without specifying how it bills is hiding the cost. A provider that gives a clear baseline plus burst pricing is being honest.
3. Can capacity be pre-scaled on a schedule, or only reactively? Reactive autoscaling alone is too slow for competition draw close windows (60 to 150 seconds reaction time vs draw spikes arriving in under 60 seconds).
4. Is there a managed migration path, or do I have to migrate myself? Standard WordPress migration plugins (All-in-One WP Migration, Duplicator) often fail on specialist hosting environments. A managed migration team is the reliable path.
5. What analytics are exposed? A hosting provider that shows PHP worker utilisation, request behaviour (normal / burst / rate-limited), edge status codes, and database query timing in real time is a provider that takes performance seriously. A provider that shows only uptime and bandwidth is not.
6. What is the support response time for live performance issues during a draw? The right answer is minutes, not hours.
7. Has the provider hosted UK competition sites at scale before? Generic managed hosting providers without specific experience of competition workloads will tune the platform for their typical customer, which is not a competition operator.

Most generic managed WordPress hosting providers fail several of these questions. The few that pass tend to be specialist providers with explicit competition or high-traffic-ecommerce experience.

The cost reality of WooCommerce hosting for competition websites

UK competition operators planning to launch on £20 per month managed WordPress hosting consistently rebuild on more substantial infrastructure within their first three to six months once draw days expose the limits. The cost of the rebuild and the lost revenue during the failure period is typically several times the cost of starting on appropriate hosting from the start.

The Performance Hosting tiers start at £99 per month for the entry-level Performance plan and scale upward with the operator’s traffic and concurrency requirements. Pricing detail and tier specifications are on the competition website hosting service page. The pricing connects directly to the pricing decisions you make on tickets and bundle structures, as covered in our raffle ticket pricing guide.

For operators currently on Shopify and considering a migration, the Shopify vs WordPress competition site comparison covers why Shopify’s platform constraints make competition operations difficult and how the hosting calculus differs between the two stacks.

What 50+ UK competition WooCommerce builds have taught us about hosting

The patterns that show up consistently across the operators we have built for:

Pre-launch hosting decisions are the cheapest hosting decisions. Operators who specify hosting infrastructure during the build phase, sized for their expected first six months of traffic with burst headroom for the unpredictable upside, almost never have draw-day failures. Operators who choose hosting on price during the build phase and rebuild later spend two to four times as much overall and lose revenue during the failure window.

Marketing platform integration is the most common single failure point. Synchronous Klaviyo and Omnisend calls during checkout are responsible for the majority of post-launch performance complaints we see. Moving these integrations onto Action Scheduler queues is a one-time engineering task that pays for itself within a single high-volume draw.

Pre-scheduled autoscaling beats reactive autoscaling for competition workloads. Operators who schedule capacity ahead of known draw close times never see the worker exhaustion patterns that catch operators relying on reactive scaling. The configuration takes minutes to set up. The benefit is permanent.

The first instant win competition is the load test. Every operator’s first instant win competition exposes the parts of the stack that were not tested under realistic concurrency. Operators who pre-test on staging with realistic load profiles avoid the public-facing failure. Operators who treat the first instant win as the test discover the failures in front of their actual customers, with measurable trust and revenue consequences.

The published LR Luxe Competitions case study details how one operator scaled from launch to 10,000+ concurrent TikTok Live players on this exact infrastructure pattern, generating £30,000 in month one and continuing month-on-month growth without re-architecting the stack. The hosting analytics referenced throughout this guide are drawn from that same site.

For UK operators planning a new competition website build or migrating an existing site that is hitting the limits of its current hosting, the Nera competition website build service includes hosting specification, application-level configuration, and managed migration as part of a single delivery, rather than as separate decisions made under draw-day pressure.