How to Load Test Your App Before Launch (And What Happens If You Don't)

Healthcare.gov's 2013 launch is the most famous load testing failure: 250,000 simultaneous users on a system tested for 200. It crashed within two hours. But this happens to startups too. A Product Hunt launch, a viral tweet, or an email blast to 50,000 subscribers can send 10x your normal traffic in minutes.

Load testing simulates real-world traffic against your application to find breaking points before they matter. It answers questions like: how many concurrent users can your system handle? Where does it bottleneck first (database, API, memory, network)? How does response time degrade as load increases? Does it recover gracefully after a traffic spike?

Skipping load testing is gambling that your launch will be small. And if your launch is small, you have bigger problems than performance.

The load testing landscape has improved dramatically. Modern tools are developer-friendly, scriptable, and run from CI/CD pipelines.

k6 (Our Recommendation)

Open-source, written by Grafana Labs. Tests are written in JavaScript. Lightweight, runs locally or in the cloud. Excellent for API and backend load testing. Free for local use; k6 Cloud starts at $99/month for distributed testing. Best for teams already using Grafana for monitoring.

Artillery

Node.js-based load testing tool. YAML configuration makes simple tests easy to write. Supports WebSocket and Socket.io testing natively. Free for local use; Artillery Cloud starts at $49/month. Best for teams that want quick setup without learning a testing DSL.

Locust

Python-based, open-source. Tests are written in Python, giving you full programming language flexibility. Built-in web UI for monitoring test execution in real-time. Free. Best for teams with Python expertise.

Gatling

JVM-based, written in Scala. Powerful for complex test scenarios. Generates detailed HTML reports. Free community edition; enterprise starts at $2,000/month. Best for enterprise teams with JVM expertise.

For most startups, k6 or Artillery is the right choice. Both have minimal setup, excellent documentation, and handle the common testing scenarios without requiring deep load testing expertise.

A load test is only useful if it simulates realistic user behavior. Hammering your home page with GET requests tells you nothing about how your app handles real traffic.

Model Real User Flows

Identify your 3 to 5 most common user journeys and script them. For an ecommerce app: browse products, search, view product detail, add to cart, checkout. For a SaaS product: login, view dashboard, create a record, edit a record, search. Include realistic think times (pauses between actions) of 2 to 5 seconds to simulate human behavior.

k6 Example

A basic k6 test ramps up from 0 to 100 virtual users over 2 minutes, holds at 100 for 5 minutes, then ramps down. Each virtual user executes your scripted flow in a loop. Monitor response times, error rates, and throughput throughout the test. k6 reports p50, p95, and p99 response times, which are more useful than averages (averages hide tail latency problems).

Key Metrics to Watch

• p95 response time: 95% of requests complete within this time. Target under 500ms for API endpoints, under 2s for page loads.
• Error rate: Percentage of requests returning 4xx/5xx errors. Target under 0.1% at your expected load. Any errors under normal load indicate bugs, not capacity issues.
• Throughput: Requests per second your system handles. This should plateau, not decline, as load increases. Declining throughput means your system is overloaded.
• Connection errors: Failed TCP connections indicate your server is running out of resources (file descriptors, memory, connections).

Load testing almost always reveals bottlenecks. Here are the most common ones and their fixes.

Database Queries

The #1 bottleneck. Queries that take 50ms with 10 users take 5,000ms with 100 users because of connection pool exhaustion and lock contention. Fix: add indexes on frequently queried columns, optimize N+1 queries (use JOINs or batch loading), increase connection pool size, and add read replicas for read-heavy workloads. Use EXPLAIN ANALYZE on slow queries to understand what PostgreSQL is actually doing.

Memory Leaks

Your application's memory usage should be roughly constant under sustained load. If it climbs continuously, you have a memory leak. Common causes: unbounded caches, event listeners that are never removed, large objects held in closures, and accumulating log buffers. Monitor memory usage during load tests and investigate any continuous increase.

Connection Limits

Every component has a connection limit: database connections (default 100 in PostgreSQL), HTTP keep-alive connections, Redis connections, and external API rate limits. Under high load, connection exhaustion cascades through your system. Fix: use connection pooling (PgBouncer for PostgreSQL), configure appropriate pool sizes, and implement circuit breakers for external services.

CPU Saturation

If CPU usage hits 80 to 90% during your load test, you are near the scaling limit of your current hardware. Options: optimize CPU-intensive code (JSON serialization, image processing, encryption), scale horizontally (add more instances behind a load balancer), or upgrade to larger instances.

DNS and External Dependencies

If your application calls external APIs during request processing (payment verification, email sending, third-party data enrichment), those external calls become bottlenecks under load. Move external calls to background jobs where possible, and set aggressive timeouts (2 to 5 seconds) on all external HTTP calls.

Different test types reveal different problems. Run all four before launch.

Baseline Test

Run your application with a single user and measure response times. This is your best-case scenario. If single-user response times are already slow, adding load will only make things worse. Fix performance issues at baseline before testing under load.

Load Test

Simulate your expected peak traffic. If you expect 500 concurrent users at peak, test at 500 concurrent users for 10 to 15 minutes. Response times should remain acceptable (under 500ms for APIs) and error rates should be near zero.

Stress Test

Push beyond expected traffic to find the breaking point. Gradually increase load until response times exceed your SLA or errors start appearing. This tells you your maximum capacity and gives you a safety margin. If your breaking point is 800 concurrent users and you expect 500, you have a 60% buffer.

Spike Test

Simulate a sudden traffic burst: go from 50 users to 500 users in 30 seconds, hold for 2 minutes, then drop back to 50. This tests auto-scaling, connection pooling, and cache warming. Many applications handle gradual load increases fine but fail under sudden spikes because auto-scaling takes 1 to 3 minutes to provision new instances.

Soak Test

Run at moderate load (50 to 70% of capacity) for 2 to 4 hours. This reveals memory leaks, connection leaks, and other issues that only appear over time. A soak test caught a PostgreSQL connection leak in one of our projects that only manifested after 90 minutes of sustained load.

Load testing should not be a one-time pre-launch activity. Integrate it into your development process to catch performance regressions before they reach production.

Automated Performance Checks

Run a lightweight load test (50 virtual users, 2-minute duration) in your CI/CD pipeline on every merge to main. Compare p95 response times against the previous baseline. If response times degrade by more than 20%, fail the build and investigate.

Pre-Release Load Tests

Before each major release, run a full load test suite against your staging environment. This catches performance issues introduced by new features. Use a staging environment that mirrors production (same instance types, same database size, same configuration). Testing on an underpowered staging server gives misleading results.

Tools for CI Integration

k6 integrates directly with GitHub Actions, GitLab CI, and Jenkins. The k6 CLI outputs results in JSON, which you can parse and assert against thresholds. Artillery also supports CI integration with its --output flag. Both tools can post results to Grafana or Datadog for historical tracking.

Load testing is one of the best ROI investments in your pre-launch budget.

• Basic load testing setup (1 to 2 days, $1K to $3K): Install k6 or Artillery, write 2 to 3 test scenarios covering your main user flows, run against staging, document results and fix critical bottlenecks. Suitable for MVP launches with modest expected traffic.
• Comprehensive load testing (3 to 5 days, $5K to $10K): Full test suite (baseline, load, stress, spike, soak), CI/CD integration, performance monitoring setup (Grafana dashboards), and a written report with optimization recommendations.
• Ongoing performance engineering ($2K to $5K/month): Continuous load testing in CI/CD, weekly performance reviews, proactive optimization, and capacity planning for growth milestones.

The Cost of NOT Load Testing

A production outage during a launch event costs more than lost revenue. It costs user trust, press coverage momentum, and team morale. A 4-hour outage for a SaaS product with 1,000 users and $100 ARPU costs approximately $550 in direct revenue plus incalculable brand damage. A $5K load testing investment prevents that scenario entirely.

We help startups prepare for launch with comprehensive load testing and performance optimization. Book a free strategy call to discuss your performance requirements.