Load Testing Before Launch: Metrics That Trigger Action

Load testing often happens the week before launch, after the marketing date is fixed. That timing turns performance work into emergency surgery. The teams hit hardest are Indian SMBs and mid-market B2B companies running a portal, a dashboard, or an internal tool that suddenly gets real traffic from a festival campaign, a partner onboarding, or a WhatsApp broadcast. The fix is not a bigger server. It is knowing which metrics to watch and which thresholds should stop the launch.

Start with the journeys that make money

Don't load test every URL equally. Pick 5-10 journeys that either make money or break trust: login with OTP, product search, checkout with UPI, payment webhook, invoice PDF generation, report export, WhatsApp send, CRM sync. For each, write down normal traffic, expected peak, and 3x peak. In our experience, a B2B portal with 1,200 daily active users might see 80 concurrent users at peak. A festival sale can push that to 300. Test the 300 number, not the 80.

Also test the ugly path. A user who retries a failed UPI payment three times, a webhook that fires twice, an admin exporting 50,000 GST invoices. These paths create more load than the happy path.

The five numbers that matter

• p95 and p99 latency. Average response time hides the users who wait. If your average is 300ms but p99 is 8s, one in a hundred requests is painful. Track p95 for core APIs and p99 for checkout, payment, and login.
• Error rate by endpoint. A 2% error rate on a dashboard is annoying. A 2% error rate on a payment webhook is a revenue leak. Separate 4xx from 5xx. 5xx should be near zero.
• Throughput at target concurrency. Measure requests per second while keeping response times under threshold. If throughput collapses when you add users, you have a bottleneck, not a capacity problem.
• Saturation. CPU, memory, database connections, thread pools, queue depth, and disk I/O. A server at 95% CPU under a test load will fail under real load. Keep CPU under 70%, memory under 80%, and DB connections under 70% of max at peak.
• Queue lag. For background jobs like email campaigns, WhatsApp broadcasts, invoice generation, and CRM sync, measure how long items wait. If queue lag grows during the test, your workers cannot keep up.

Consider a typical mid-market portal: a single 4 vCPU app server and a 2 vCPU Postgres instance. At 80 concurrent users, p95 was 450ms. At 240 concurrent users (3x peak), p95 hit 2.8s, DB CPU touched 95%, and checkout throughput fell from 12 RPS to 6 RPS. The fixes were not exotic: add a read replica for reports, move PDF generation to a queue, cache the product catalog, and raise the connection pool. After re-testing, p95 was 620ms at 40 RPS with CPU at 65%. That is a launchable system.

Thresholds that should stop a launch

Use these as action triggers, not absolute laws. Adjust for your domain. But if you see these numbers, do not launch without a fix or a rollback plan.

• p95 > 800ms on core API for 10 minutes → optimize queries, add cache, or scale.
• p99 > 2s on checkout, login, or payment webhook → block launch.
• 5xx error rate > 0.5% overall, or any on payment/webhook → block launch.
• CPU > 80% at 1.5x expected peak → add capacity or fix the hot path.
• DB connections > 80% of max → add pooling (PgBouncer, RDS Proxy) or reduce query time.
• Queue lag > 5 minutes and growing → scale workers or batch jobs.
• Load balancer or API gateway 5xx during ramp → check timeouts, keep-alive, and upstream limits.
• Third-party API failures > 1% (payment, SMS, WhatsApp, e-invoice) → add retries with backoff and idempotency.

One more trigger: if you cannot explain why a metric crossed a threshold, do not launch. Unexplained behaviour in a test becomes an outage in production.

What teams forget to test

• Third-party services. Your payment gateway, SMS provider, WhatsApp Business API, email service, GST e-invoice portal, and courier APIs have rate limits and timeouts. Mock them in early tests, then run one test against sandbox endpoints.
• Background jobs. A WhatsApp broadcast to 20,000 contacts or an email campaign to 50,000 subscribers can saturate workers, database, and outbound IPs. Test with a realistic list size.
• Data volume. A test against 1,000 rows proves nothing. Use production-like data: 100,000+ orders, 500,000 contacts, 2 years of invoices.
• Cold starts and autoscaling. Serverless functions in Mumbai or containers behind a load balancer take time to warm up. Test a sudden jump from 10 to 200 users.
• Mobile networks. Your office Wi-Fi is not a Jio 4G connection in Indore. Throttle to 3G/4G and test again.
• Failure injection. Kill the database, throttle the network, expire a certificate. See how the system degrades.

Where to start

Pick one critical journey. Set a target: 2x expected peak for 30 minutes. Use k6, Locust, or JMeter, run it on production-like infrastructure in the same region as your users, and watch p95, error rate, CPU, DB connections, and queue lag. Fix the first bottleneck, then re-run. Two or three cycles typically take 2-6 weeks, depending on how much needs to change. If you want a second pair of eyes on the plan or the results, Maysan Labs builds web platforms and internal tools and can help you run a launch-readiness test without over-engineering it.