Launching without performance testing is gambling with user experience, infrastructure costs, and business revenue. This checklist ensures nothing is missed. Use it as a formal quality gate: every item must be addressed (completed or explicitly accepted as a known risk) before approving a production launch.
Section 1: Load profile definition
Before writing a single test script, you need to know what realistic load looks like. Testing without accurate load profiles is like stress-testing a bridge without knowing how many trucks will cross it.
Expected concurrent users. Document peak, average, and minimum concurrent user counts. Source these from business projections, analytics from existing systems, or competitor benchmarks. Include growth projections for 6 and 12 months post-launch.
Traffic patterns. Map the expected daily traffic curve: when are peaks, when are valleys. Identify weekly patterns (Monday mornings vs weekends) and seasonal spikes (Black Friday, end-of-quarter, marketing campaign launches). Your load profile must simulate these patterns, not just flat load.
User journey distribution. Not all users do the same thing. Define the percentage split across key journeys: 40% browse only, 25% search and browse, 20% add to cart, 10% complete purchase, 5% account management. This distribution drives realistic scenario mixing.
Data volume projections. How much data will the database hold at launch, at 6 months, and at 12 months? Performance with 10,000 records is meaningless if production will have 10 million. Test with production-scale data volumes.
Third-party dependency load. Identify every external API, payment gateway, CDN, and service your application calls. Document their rate limits, expected latency, and failure modes. Your performance tests must account for these dependencies.
Section 2: Test environment readiness
Performance test results are only valid if the test environment accurately represents production.
Infrastructure parity. The test environment must match production in architecture, not necessarily in scale. Same database engine, same caching layer, same load balancer configuration, same CDN setup. If production runs on 4 application servers, test on 2 minimum and extrapolate, but never test on a single server and assume it scales linearly.
Data preparation. Load production-scale data into the test environment. This includes database records, file storage, cache warm-up data, and search indices. Performance characteristics change dramatically between empty and full databases.
Network configuration. Ensure the test environment has the same network topology as production: same firewall rules, same DNS resolution, same SSL/TLS configuration. Test from outside the internal network to include real network latency.
Monitoring instrumentation. Application Performance Monitoring (APM) must be active during tests. Server metrics (CPU, memory, disk I/O, network), application metrics (response times, error rates, throughput), and database metrics (query times, connection pool usage, lock contention) must all be captured.
Isolation. The test environment must be isolated from other activities during performance tests. Shared environments produce unreliable results because other workloads affect resource availability.
Section 3: Test scenario design
Each test scenario targets a specific performance risk. Cover all five types.
Load test. Simulate expected peak load for a sustained period (minimum 30 minutes, ideally 2 hours). Validates that the system handles normal peak traffic without degradation. This is the most important test and must pass before launch.
Stress test. Gradually increase load beyond expected peak until the system degrades or fails. Identifies the breaking point and how the system behaves under overload. Does it degrade gracefully (slower responses) or catastrophically (crashes, data corruption)? Document the exact load level where response times exceed acceptance criteria.
Spike test. Apply sudden load increases (0 to peak in under 60 seconds) to test auto-scaling and recovery. Simulates viral content, flash sales, or DDoS-like traffic patterns. Measures how quickly the system scales up and stabilizes.
Soak test (endurance). Run at moderate load (60-70% of peak) for 8-24 hours. Reveals memory leaks, connection pool exhaustion, log file growth, and other issues that only manifest over time. Many applications pass short load tests but fail in production after running for days.
Failover test. Kill components during load: application server instance, database replica, cache server, external service. Validates that redundancy works under load and that failover does not cause request failures or data loss.
Section 4: Acceptance criteria
Every performance test needs pass/fail criteria defined before execution. Testing without acceptance criteria produces data without decisions.
Response time thresholds. Define p50, p95, and p99 targets for each critical endpoint. Example: homepage p95 under 800ms, search results p95 under 1.5 seconds, checkout completion p95 under 2 seconds. Use percentiles, not averages. An average of 500ms can hide a p99 of 10 seconds.
Throughput minimums. Define minimum transactions per second the system must sustain at peak load. This is derived from your load profile: concurrent users multiplied by actions per minute.
Error rate maximums. Define the maximum acceptable error rate under load. Industry standard is less than 0.1% for critical transactions (payments, data submissions) and less than 1% for non-critical endpoints. Any 5xx errors on core journeys should be zero.
Resource utilization ceilings. CPU under 70% at peak load (leaves headroom for spikes), memory under 80% (prevents OOM kills), database connections under 70% of pool maximum, disk I/O not hitting hardware limits. Exceeding these at expected peak means production will have no buffer.
Scalability targets. If auto-scaling is configured, define maximum scale-up time (under 3 minutes), maximum cost at peak load, and scale-down behavior after load subsides.
Section 5: Monitoring and alerting setup
Performance testing is not just about the test run. It is about having the monitoring in place to catch performance issues after launch.
Real-time dashboards. Before launch, create dashboards showing response time percentiles, error rates, throughput, and resource utilization for every critical service. These dashboards must be accessible to the entire engineering and operations team.
Alerting thresholds. Configure alerts based on your acceptance criteria. Response time p95 exceeding threshold for 5 consecutive minutes triggers a warning. Error rate exceeding maximum triggers a critical alert. Resource utilization exceeding ceiling triggers capacity planning review.
Synthetic monitoring. Set up synthetic transactions that continuously test critical user journeys from external locations. These run every 1-5 minutes and provide immediate detection of performance degradation or outages, independent of real user traffic.
Log aggregation. Ensure application logs, web server logs, and database slow query logs are aggregated and searchable. During the first week post-launch, you will need to investigate performance anomalies quickly.
Baseline documentation. Record performance test results as the official baseline. Post-launch metrics should be compared against these baselines to detect regression. Store results in a format that allows historical comparison across releases.
The pre-launch sign-off process
Before approving launch, review results against every acceptance criterion. Create a performance test report documenting load profiles tested, results per scenario, acceptance criteria met and failed, identified risks and mitigations, and infrastructure recommendations. All stakeholders (engineering lead, QA lead, operations, product owner) must sign off. Any failed acceptance criteria must be either fixed and retested or formally accepted as known risk with a documented mitigation plan.
How ARDURA Consulting accelerates performance testing
Performance testing requires specialized skills: load test script development, infrastructure analysis, bottleneck identification, and optimization. These skills are expensive to maintain in-house for teams that only need them periodically.
500+ senior specialists in the ARDURA Consulting network include performance engineers experienced with JMeter, k6, Gatling, and Locust. They have tested applications serving millions of users across e-commerce, fintech, and SaaS platforms.
2-week onboarding means your performance engineer starts designing load profiles and test scenarios immediately. No 3-month recruitment process when your launch date is 6 weeks away.
40% average cost savings compared to Western European rates. A 6-week performance testing engagement through ARDURA Consulting costs significantly less than hiring a full-time performance engineer, while delivering the same expertise for your critical launch window.
With 211+ successfully delivered projects, ARDURA Consulting has supported pre-launch performance validation for applications across industries. Contact us to staff your performance testing before the next launch.