A capacity test answers a specific question: can an important business workflow meet its agreed service target under the workload you expect? It should produce a decision record, not just a graph showing that a server became busy.
Use this worksheet when you already have a workload and an upgrade candidate. For investment priorities and ownership, start with the IT infrastructure growth roadmap.
Define the pass condition before running a test
Choose an end-to-end journey such as searching for a product, submitting an order and receiving confirmation. Write down what counts as success, which failures count as errors and the response-time measure you will examine. An average can hide a poor experience for slower requests, so include a tail measure such as the 95th percentile.
Set targets from customer needs and service commitments. The numbers below are an illustrative planning example, not universal standards or measurements from Make Business.
| Measure | Example target | Evidence to retain |
|---|---|---|
| Completed checkout journey | At least 99% of test journeys succeed | Successful and failed journey counts |
| Checkout response time | 95th percentile below two seconds | Response-time distribution at each load level |
| Duplicate orders | Zero duplicates in the test dataset | Reconciled test-order identifiers |
| Test cost | Within the approved test budget | Resource usage and billing estimate |
Create a safe and representative test
Use an authorised environment with relevant production characteristics and synthetic or properly sanitised data. Prevent test orders, payments, messages and fulfilment actions from reaching real customers. Check provider testing rules, obtain any required approval and agree stop conditions before generating traffic.
Document differences from production. A smaller database, omitted payment dependency or disabled background job can make the test look better than the actual service. Such differences limit the conclusion; they do not disappear because the test passed.
Increase workload in stages
- Run a small baseline to check that the scenario and monitoring work.
- Test the expected normal workload and then the forecast peak.
- If authorised, test beyond the forecast to locate the first constraint.
- Hold a steady load long enough to observe queues, memory growth or throttling relevant to the service.
- Reduce the load and check whether the system and pending work recover.
Keep application errors, database timing, queue length, external-service limits and resource use alongside journey results. High processor usage alone does not identify the cause of a failed customer workflow.
Change one hypothesis and compare again
Suppose the checkout slows while a database query consumes most of the journey time. Test the query improvement before buying more application servers. Keep the scenario, dataset and workload comparable, record what changed and rerun the same acceptance checks.
If a provider rate limit is the first constraint, extra local computing capacity may not help. The next decision could concern request scheduling, a contract limit or an alternative workflow. Record that dependency explicitly.
Publish a decision record
Retain the test date, environment, scenario, dataset, load levels, observed failures, accepted limitations and owner. End with a concrete decision: proceed, revise and retest, or reject the proposed upgrade. Include a rollback trigger and the production measurements that will confirm the change after release.
For the underlying practice, see AWS guidance on load testing. Its requirements for representative workloads, monitoring and documented results should be adapted to your environment.
If the team needs outside help to design or interpret the test, read when to hire a technology consultant. More related planning resources are in the Technology section.
