Load Testing vs Stress Testing: Goals, Metrics, and When to Use Each

A checkout service can meet its response-time targets during a forecast sales peak and still remain unhealthy after an unexpected surge. Requests may accumulate faster than workers can process them, leaving orders delayed after incoming traffic falls. A release decision needs evidence about the expected workload; a capacity decision also needs evidence about overload and recovery.

Load testing validates performance against requirements at an expected workload. Stress testing, in the beyond-capacity sense used here, explores the limits of the system, its failure behavior, and its ability to recover. The same transaction scripts can support both, but their targets and conclusions differ.

Choose the Question Before the Traffic Pattern

An acceptance-oriented load test starts with a workload forecast and agreed performance targets. That workload can represent normal traffic or a planned peak. The question is whether the deployed candidate handles that demand correctly within the required latency, throughput, and resource constraints.

A stress investigation moves beyond the accepted workload toward capacity limits, within an authorized safety envelope. It identifies where useful throughput stops keeping pace with demand, which constraints appear, and what happens after pressure is reduced. Finding a limit is an expected outcome, while data corruption or failed recovery can violate explicit resilience requirements.

Terminology varies across tools. Grafana k6 describes stress testing as heavier-than-usual load and separately describes breakpoint testing as increasing load to find limits. Other vendors use stress testing for that limit-finding activity. State the intended workload, objective, and stopping rules in the test plan rather than relying on the label alone.

Decision Criterion	Load Testing	Beyond-Capacity Stress Testing
Main question	Does the candidate meet requirements at expected demand?	Where does service degrade, how does it fail, and does it recover?
Workload boundary	Defined operating envelope, including a forecast peak	Increasing demand beyond that envelope, subject to safety limits
Required evidence	Delivered workload, operation-level targets, correctness, and stability	Degradation boundaries, constrained resources, failure modes, and recovery
Result	Acceptance or rejection of the tested operating conditions	Characterized limits plus evaluation of resilience requirements
Typical decision	Release readiness for the forecast workload	Capacity investment, overload controls, and recovery improvements

A ramp does not make a test a stress test. Both tests may use a gradual increase followed by a plateau. A sudden spike examines the response to rapid change, while a long soak examines sustained-use problems. Traffic shape and duration should follow the risk being investigated, not substitute for the test objective.

Define One Representative Workload

Consider a fictional retail API with catalogue reads, searches, and asynchronous order creation. Its team forecasts a peak of 120 new operations per second lasting 30 minutes. The planned mix is 60% catalogue reads, 30% searches, and 10% order creation. That produces 72 catalogue reads, 36 searches, and 12 order-creation requests per second.

These are illustrative planning assumptions, not measured results or industry benchmarks. Each operation makes one initial HTTP request in this simplified model. Order creation returns an acceptance response before a worker completes the order. Completion observation, health checks, and retries are accounted for separately, so they cannot silently inflate the advertised operation rate.

The dataset must exercise the work those operations normally require. Use representative catalogue sizes, search terms, result counts, payload sizes, and customer-history distributions. Repeatedly reading one cached product or placing every order through one account can create a misleading bottleneck or hide an expensive path. Record the intended cache state, data version, and reset procedure. The guide to safe, repeatable test data explains how isolation, relationships, and dataset readiness support reproducible tests.

Keep application version, instance sizes, database configuration, worker count, and dependency behavior identifiable. An approved sandbox or controlled dependency substitute may be necessary to avoid real payments and messages. Record that substitution as a limitation: the result does not establish the real provider's capacity or latency.

Match Arrival Rate, Concurrency, and Think Time

For this scenario, new operations arrive independently of earlier responses, so an open arrival-rate model fits the forecast. Concurrent virtual users are the execution capacity needed to sustain that demand; they are not interchangeable with requests per second. A journey can also contain several requests, making journey starts, active users, and HTTP request rate different measurements.

In a closed model, each virtual user waits for its current work to finish before continuing, usually with configured think time. If responses slow down, that fixed population may generate fewer new operations. This can be appropriate for a genuinely bounded population, but it can understate pressure when real customers keep arriving. k6 documents this feedback problem as coordinated omission in its open-versus-closed model guidance.

Model human pauses within journeys when they belong to the observed behavior. Do not add arbitrary sleeps to an arrival-driven operation test and assume the original demand still holds. In Locust, waits apply to tasks, and a task can contain multiple requests. Check the resulting operation mix and request rate rather than inferring them from task weights alone.

The generator needs its own telemetry. Compare scheduled starts with actual starts, completions, and dropped work; inspect its CPU, memory, sockets, and network usage. In k6, dropped iterations can reflect insufficient virtual-user allocation or longer application iterations that consume the available users. The counter alone does not identify the cause. An overloaded generator cannot establish the application's capacity ceiling.

Validate the Expected Peak Against Named Targets

First validate script behavior and business assertions at minimal traffic. For the fictional acceptance run, ramp to 120 operations per second over five minutes, then hold the expected peak for 30 minutes before ramping down. The hold matches this scenario's assumed peak duration. Another application may need a different window, and this run cannot rule out problems that emerge only after hours of sustained use.

Before execution, the fictional team agrees on these targets for the steady phase:

• Successful catalogue, search, and order-acceptance responses have p95 latency no greater than 400, 700, and 900 milliseconds respectively. Each operation class also has p99 latency no greater than 1,500 milliseconds.
• Fewer than 0.5% of valid operations in each class fail, counting transport errors, timeouts, unexpected responses, and failed business assertions. An overload rejection at expected demand counts as a failed operation.
• The generator starts all scheduled operations, the service sustains the offered mix without persistent backlog growth, and accepted orders complete with p95 no greater than 30 seconds.
• No accepted order is lost or duplicated, verified by reconciling submitted operation identities with resulting order records after processing settles.

Every value above is an example requirement for this invented system. Choose real thresholds from user expectations, service objectives, architecture, and the workload forecast. Copying a documentation example's p95 or error budget does not create a justified release criterion.

Report percentiles by operation and phase, with sample counts and error denominators. The p95 describes the latency at or below which approximately 95% of the measured observations fall; it is not an average. A global percentile dominated by fast catalogue reads can conceal slow order acceptance. A whole-run summary can also dilute a degraded steady period with quieter ramp-up and ramp-down observations.

Measure failed-response latency separately from successful-response latency. Fast rejections can make a blended response-time graph look better while customers complete less useful work. Likewise, HTTP request throughput is not successful order throughput, and a quick acceptance response does not establish prompt asynchronous completion.

A clean latency result is insufficient if the generator missed the required arrivals or the order queue grew throughout the plateau. Treat a workload-generation problem as an invalid acceptance result requiring correction. Treat a verified target breach under the delivered workload as an acceptance failure requiring investigation, rather than lowering the target after seeing the result.

Explore Overload With Boundaries and a Recovery Phase

Run this investigation only in an explicitly authorized, isolated environment. Identify the owner, affected dependencies, traffic cap, maximum duration, cost limit, and abort conditions before starting. Keep production endpoints and real customer effects outside the test path. Provide a stop mechanism and an agreed procedure for restoring the environment.

Reuse the operation definitions, mix, and representative data so changes in behavior can be related to demand. For this fictional plan, observe stages at 160, 200, and 240 operations per second, with five-minute plateaus and controlled transitions. These are selected observation points under an approved cap, not a universal stress-to-load ratio. Stop earlier if safety conditions are reached. If no capacity boundary appears before the cap, report that the limit was not found within the tested envelope.

Compare offered demand, actual starts, successful completions, latency percentiles, error classes, and queue growth at each stage. Useful throughput may flatten while queued work and tail latency continue rising. Correlate those changes with database connection waits, worker occupancy, CPU, memory pressure, garbage collection, disk or network constraints, and dependency latency. A correlated metric suggests an investigation; it does not prove the root cause by itself.

Classify errors by their meaning and origin. A deliberate overload rejection can demonstrate a protection mechanism, although the rejected user operation still failed. An unexpected server error, gateway timeout, exhausted dependency quota, transport failure, and incorrect business response need different evidence. Do not label every HTTP 5xx response an application-code defect or treat every HTTP 200 response as business success.

Record retry policy and retry traffic separately. Retries can increase work when the system is already constrained, and a final success can conceal earlier failed attempts. If autoscaling is enabled, retain replica counts, scaling limits, and timing alongside the results. A fixed-resource capacity experiment and a production-like elasticity experiment answer different questions; neither should have an unbounded spending envelope.

Require Recovery at the Original Workload

After the overload phase, return the fictional workload to 120 operations per second rather than immediately stopping all traffic. Observe whether the service can again handle the demand it previously accepted. Reducing traffic to zero can hide a queue or pool problem that reappears as soon as customers return.

For this example, recovery requires the original latency, failure, and completion targets to hold again, with queue depth and oldest-item age back inside their recorded pre-stress operating bands. They must remain there for two continuous minutes, with that stable window completed within five minutes of returning to the original arrival rate. Those times are fictional requirements, not tool defaults.

Reconcile accepted orders for missing or duplicate results, and confirm that retries or delayed workers have not produced late inconsistencies. Record any restart, manual queue repair, configuration change, or other intervention. If intervention was necessary, the evidence does not demonstrate automatic recovery. Reaching the observation deadline without recovery is a result to report, not permission to keep extending the window until the chart looks healthy.

Run Each Test When the Decision Changes

Use an expected-load test when the release changes work performed at the forecast demand: a database query, search implementation, payload size, cache policy, connection pool, or dependency configuration. Revisit the workload when a campaign forecast, customer population, or operation mix changes. Passing an old workload does not validate a new demand profile.

Repeat limit and recovery exploration when architecture, scaling policy, worker capacity, quotas, overload protection, or retry behavior changes enough to invalidate earlier evidence. A relevant saturation incident is another trigger. Follow the investigation with expected-load acceptance on the candidate being considered; a higher discovered ceiling does not prove that its normal operating targets still hold.

Keep verdicts separate even when phases share scripts. A combined sequence can provide useful evidence if each phase has explicit targets and the cache, data, and resource conditions are recorded. Separate runs are clearer when overload would contaminate the acceptance baseline. Preserve failed runs and identify the candidate, workload, environment, observed boundary, recovery outcome, and unresolved limitations in the decision record.

A candidate that misses agreed targets at expected demand lacks the required acceptance evidence. Deliberate shedding beyond that demand may be acceptable if it matches the approved protection policy and recovery requirements. Corrupted accepted work or failure to recover breaches this example's resilience gate, even if the expected-load phase passed.

Start the next performance review by agreeing on the workload the service must accept and the recovery behavior it must demonstrate after overload. Those commitments determine which test to run, what to measure, and which result can support the release decision.