Your Site Crashes During Sales: Load Testing and Preparation

Your Black Friday sale starts at midnight. By 12:03 AM, your site is down. Customers are complaining on social media. Your payment gateway is timing out. Your developers are frantically restarting servers while you watch potential sales evaporate.

This scenario plays out every year for ecommerce businesses that haven’t properly tested their infrastructure. The frustrating part? It’s entirely preventable.

What Actually Breaks During Traffic Spikes

Most business owners assume crashes happen because “too many people visited at once.” That’s partially true, but incomplete. Sites don’t fail uniformly. They fail at specific bottlenecks that normal traffic never exposes.

The real culprits:

Your site search might work perfectly for 50 concurrent users but grind to a halt at 200 because each search query hits the database multiple times. Your checkout process might handle normal traffic but timeout during sales when hundreds of people simultaneously process payments. Your product filtering might be fast normally but become unusably slow when traffic spikes expose inefficient database queries.

A UK equestrian retailer called LeMieux discovered this the hard way. They load tested their site before Black Friday, determined their capacity, and set up systems to control traffic flow. Everything looked ready. Then on sale day, their site slowed to a crawl. The problem wasn’t checkout volume, but customers using the search and filter features. The load test had focused on order volume, not how customers actually browse.

The lesson: crashes happen at specific bottlenecks, not from generic “too much traffic.” You need to test realistic user behaviour, not just visitor counts.

The Business Cost of Crashes

A one-second delay in page load time reduces conversions by 7%. During high-traffic sales, that compounds quickly.

Consider the typical Australian ecommerce business doing $2 million annually, with 30% of annual revenue coming from major sale periods (Black Friday, Boxing Day, end of financial year). That’s $600,000 in sales concentrated into a few days.

If your site is down for three hours during a 24-hour Black Friday sale, you’ve lost 12.5% of potential sales (approximately $25,000 for this business). If the site is slow but functional, degrading from 2-second to 5-second load times, you’re losing roughly 21% of conversions during the critical period (around $42,000).

Beyond immediate revenue loss, there’s reputational damage. Customers who encounter a crashed site during a sale are unlikely to return. They’ll simply buy from a competitor whose site works.

What Load Testing Actually Does

Load testing simulates high traffic before your actual sale to identify breaking points. You’re essentially stress-testing your infrastructure in a controlled environment to find problems while you still have time to fix them.

The process involves generating realistic user behaviour at scale. Hundreds or thousands of virtual users browse products, search, add items to cart, and complete checkout. Then you measure how your site responds. Where do response times spike? What errors appear? At what point does the site become unusably slow or crash entirely?

Importantly, finding problems during load testing is good news. It means you’ve discovered issues before real customers encountered them. A site that crashes during testing would almost certainly crash under real traffic. Now you know what to fix.

Testing Realistic User Behaviour

The biggest mistake in load testing is testing volume without testing behaviour.

Simply hitting your homepage with 10,000 requests doesn’t tell you much. Real customers don’t just load the homepage. They search for products, filter by category, view multiple product pages, add items to cart, apply discount codes, and complete checkout. Each action places different demands on your infrastructure.

Critical user paths to test:

• Product search and filtering (often the most database-intensive operations on ecommerce sites)
• Category browsing and pagination (can expose N+1 query problems at scale)
• Adding items to cart (tests session management and database writes under load)
• Applying discount codes (often involves complex calculations that slow down under concurrent use)
• Checkout and payment processing (the most critical path; any failure here directly costs sales)

Run tests that replicate your actual traffic patterns. If 40% of customers use search, 60% browse categories, and 15% complete checkout, your load test should reflect those percentages. If mobile traffic is 65% of your total, test mobile user flows.

How Much Traffic Should You Test For

Look at your historical data from previous sales to establish baseline expectations.

If last year’s Black Friday brought 500 concurrent users at peak, test for 750-1,000. Traffic tends to grow year-over-year, and it’s better to over-prepare. If you’re running a significantly larger marketing campaign this year, factor that growth into your estimates.

Pay attention to concurrent users, not total daily visitors. Your site might handle 50,000 visitors across 24 hours easily, but if 2,000 arrive in the same five-minute window, that’s what stress tests your infrastructure.

Practical approach:

Start with your expected peak concurrent users. Run a test at 1.5x your expected peak to build in a safety margin. Push beyond that to find your actual breaking point. When does the site become slow? When does it crash? Identify which specific features or pages fail first. Use that information to prioritise optimisation efforts.

Common Bottlenecks That Emerge

Load testing typically reveals problems in predictable areas. When those problems do surface in production, understanding what those HTTP error codes actually mean helps you tell a real emergency from background noise.

Database queries are the most common bottleneck. Your product catalogue might load quickly for one user but timeout when 500 users simultaneously request filtered results. This often indicates N+1 query problems, missing database indexes, or inefficient query structures.

Search functionality is frequently performance-intensive. Customers typing queries, filtering results, and sorting products can generate complex database operations. Under load, these become exponentially slower.

Third-party integrations introduce external dependencies you don’t control. Payment gateways, shipping calculators, inventory systems, and analytics tools can all become bottlenecks. If a third-party API slows down or becomes unresponsive, it can cascade through your entire checkout process.

Session management can fail under concurrent load. Shopping carts rely on server-side sessions or cookies. When thousands of users are simultaneously adding items, updating quantities, and checking out, poorly configured session handling can cause errors or data loss.

Static asset delivery (images, CSS, JavaScript) can overwhelm servers if not properly optimised. A product page with 50 unoptimised images might load acceptably for normal traffic but grind to a halt during sales.

Preparing Your Infrastructure

Once load testing identifies problems, you need to address them before your sale.

Optimise database performance: Add indexes to frequently queried fields. Fix N+1 query problems by loading related data in batch. Cache frequently accessed data like category lists and popular products. Review slow query logs and optimise the worst offenders.

Scale server capacity: Work with your hosting provider to temporarily increase resources during sale periods. Most cloud providers offer elastic scaling, which automatically adds server capacity when traffic spikes. Load balancing distributes traffic across multiple servers rather than overwhelming a single instance.

Implement caching: Cache database queries, API responses, and rendered page fragments. Use a Content Delivery Network (CDN) for static assets like images, CSS, and JavaScript. Browser caching reduces repeat requests from the same users.

Optimise critical paths: Ensure checkout works flawlessly even if other features degrade. Consider temporarily simplifying or disabling non-essential features during peak load. Advanced search filters, product recommendations, or dynamic personalisation can be performance-intensive. A simple site that works is better than an advanced site that crashes.

Set up monitoring: Real-time monitoring during your sale lets you respond quickly if problems emerge. Track server CPU and memory usage, database query times, error rates, and page load times. Set up alerts for concerning metrics so you’re notified immediately if something degrades.

Load Testing Tools and Costs

Load testing doesn’t require enterprise-level budgets. Several tools provide free or low-cost options.

Apache JMeter is open-source and free. It requires more technical expertise to set up but offers comprehensive testing capabilities for those comfortable with the learning curve.

Gatling provides a free open-source version with scripting in Java, Kotlin, or Scala. The paid Enterprise version adds distributed load testing and detailed reporting for businesses needing more sophisticated testing.

Loadster offers cloud-based load testing with straightforward monthly pricing. Tests typically start within 2-3 minutes using managed AWS infrastructure. No installation required.

LoadView provides stress testing from multiple geographic locations, useful for testing how your site performs for international customers.

For most Australian ecommerce businesses, the initial investment is modest. You’ll spend anywhere from free (using open-source tools and your team’s time) to a few hundred dollars monthly for commercial tools. Compare that to the potential cost of a crashed site during your busiest sales period.

Working With Your Developer

If you’re working with an external developer or agency, load testing should be an explicit part of your sale preparation.

Establish clear expectations: What concurrent user load should the site handle? What response times are acceptable (typically under 2-3 seconds)? What’s the timeline for testing and implementing fixes?

Require realistic test scenarios: Ensure they’re testing actual user behaviour, not just homepage requests. Ask to review the test plan before execution.

Understand the iterative process: Load testing usually reveals problems that require fixes, then retesting. This is normal. Build time into your schedule for multiple test-and-fix cycles.

Get detailed reports: You should receive documentation of what was tested, what breaking points were found, what optimisations were implemented, and what capacity the site can now handle.

Notify your hosting provider: Running a load test without warning can look like a DDoS attack. Many providers consider unauthorized load testing a terms-of-service violation. Coordinate with your host beforehand.

When to Load Test

Load testing isn’t a one-time event. Your site changes constantly. New features, code updates, plugin changes, platform updates can all introduce performance issues.

Minimum schedule:

Before any major sale or campaign (Black Friday, Boxing Day, major product launch). After significant platform changes or upgrades. After adding resource-intensive features (new search, personalisation, recommendation engines). Quarterly for high-traffic sites to catch gradual performance degradation.

The closer to your sale you test, the more accurate your results, but the less time you have to fix problems. Ideally, run your first load test 4-6 weeks before a major sale. This gives you time to identify issues, implement fixes, and retest to verify improvements.

What to Do If Your Site Crashes Anyway

Despite your best preparation, unexpected issues can emerge during actual sales.

Immediate response: Check if it’s a hosting provider issue and contact their support immediately. Review monitoring to identify what specifically is failing. If possible, temporarily disable non-critical features to reduce load. Reduce traffic flow if you have a virtual waiting room or queue system. Communicate transparently with customers via social media about the issue and expected resolution.

Don’t panic and rebuild: The middle of a crashed sale is not the time to make major architectural decisions. Focus on getting back online with your current system. Post-mortem analysis can happen after the sale ends.

Document everything: Once resolved, document what failed, why, and how it was fixed. Use this information to improve your next load testing cycle and prevent recurrence.

The Bottom Line

Traffic spikes are predictable. Sales events happen on known dates. Customer behaviour follows patterns. The tools to test your infrastructure are accessible and affordable.

The question isn’t whether you can afford load testing. It’s whether you can afford not to. A few hours of testing and a modest budget for infrastructure improvements can prevent catastrophic failures during your most profitable days.

Your site either works during sales, or it costs you money. Load testing ensures it works.