Agree the question and the limits
Define the important journeys, expected traffic, response-time targets and acceptable errors. Select the environment, record differences from production and agree stop conditions.
Load testing for websites and APIs.
Find out how your application behaves as traffic grows. We adapt website and API scenarios to your system, run controlled experiments and explain the results, using our existing testing platform to support repeatable checks.
From $2,000 USD · Compare packages
Discuss your project When this
work matters.
- You need to check readiness for a promotion.
- A new platform or major release needs a capacity assessment.
- Problems appear under load but are difficult to reproduce.
One platform.
Different pressures.
A steady baseline, a sudden peak and sustained demand answer different questions. The workload model determines what a test can prove.
Relative loadHigher
StartTest durationEnd
Establish the baseline.
Hold a representative workload. Observe response times, errors and resource use before increasing pressure.
Illustrative workload shapes. Not client data or measured results.
How we
work through it.
Adapt scenarios and test data
Map the HTTP requests, input data and response checks for your application. Agree the steps and variants included in each scenario. Authentication, checkout, payments and external services need their own assessment.
Prepare the test environment
Configure our platform for the agreed target and available monitoring. Check data quality and generator capacity so a limitation of the test setup is not mistaken for a limitation of your application.
Run the agreed experiments
Apply the chosen traffic levels and record response times, errors and completed operations. A capacity investigation uses a series of levels; stress and sustained-load experiments are scoped explicitly.
Explain the evidence
Review the results alongside available application and infrastructure metrics. Describe the observed limitations, prioritize recommendations and discuss what to improve or test next.
What your
team takes away.
- Documented scenarios, workload, environment and test conditions
- Result tables and charts with response times and errors
- Observed limitations with supporting evidence and analysis boundaries
- Prioritized recommendations and a proposed retest scope
- An engineer-led discussion of the findings; delivery format agreed in advance
Choose the depth of the investigation.
Prices in USD, for one prepared environment. We confirm scenario complexity, available data and monitoring before agreeing the scope.
Baseline · $2,000
Check an agreed target load.
Up to 3 agreed HTTP or API scenarios, target-load testing, initial analysis using available metrics, and a report with recommendations.
A full search for the capacity limit and implementation of fixes are outside this scope.
Capacity · $3,000
Investigate how performance changes as load grows.
Up to 6 agreed scenarios, a series of load levels and a scoped stress experiment. Includes analysis of observable components, prioritized recommendations and an initial estimate for improvements.
The report distinguishes a confirmed load level from an application limit. Implementation of fixes is quoted separately.
Improve & retest · $4,000
Investigate limitations and verify a focused improvement.
Up to 10 agreed scenarios, an extended experiment series and analysis of scaling options. Includes up to 12 hours of agreed optimization and a follow-up check within the project budget.
The optimization task is selected after assessment. This does not guarantee that every limitation can be removed within the included time.
Agree the boundaries before the test.
One scenario has a defined scope.
A scenario is an agreed journey or API operation with specific steps, data and checks. Roles, variants, one-time passwords and integrations are not unlimited additions to that scenario. Each new application needs adaptation.
Additional setup is estimated separately.
Packages assume a prepared environment, accessible APIs, suitable test data and agreed metrics. Infrastructure rental, building a test environment or monitoring from scratch, complex authentication, payments, distributed generators, long tests and non-standard protocols require a separate estimate.
Test outcomes depend on the evidence.
We confirm load only for the tested scenarios, timing and environment. If a series stops at the agreed budget or generator limit, that is not proof of the application’s maximum capacity. Stress testing alone does not establish resilience to infrastructure failures.
An existing platform. An engineer-led service.
QA Panel + k6 + Grafana
Our platform supports scenario preparation, controlled runs, saved results and comparisons. k6 generates the HTTP load; QA Panel manages the work and its history; Grafana helps inspect run and request metrics. We adapt this foundation to your system rather than build the testing tools from scratch for each engagement.
Measurements need interpretation.
Response times, errors, request rates and available activity metrics describe the experiment. An engineer checks the conditions, investigates limitations and prepares recommendations. The service is not a self-service SaaS or an automatic bottleneck detector.
Repeat the test after a change.
Compare releases under known conditions.
For an existing project, we review changes to scenarios and data, agree a limited test series and compare the results. Differences in the environment or workload are included in the interpretation. Repeat checks are scoped separately unless included in the chosen package.
Plan ongoing work around engineering time.
Follow-up support can reserve time for agreed checks and analysis. It does not mean unlimited runs, unattended regression testing or round-the-clock monitoring. Permanent platform deployment and access after the engagement are separate terms.
Before
we begin.
How many users can our website support?
We can confirm a tested load level for an agreed behavior model and quality criteria. Virtual users are scripted activity, not a direct count of online shoppers. Requests per second also depend on scenario steps and pauses. If every tested level passes, the report says the limit was not reached.
What access and data do you need?
We agree access to the target environment, API details and suitable test data. Server metrics and logs help explain internal causes; without them, analysis is limited to what the requests and available telemetry show. Access is arranged separately, not through the enquiry form.
Does this test browser rendering or Core Web Vitals?
These load tests exercise HTTP requests and API operations. They do not render pages in a browser or measure Core Web Vitals under load. Browser performance work is a separate scope.
Are fixes and a follow-up test included?
The initial scope states whether implementation and a retest are included. Your team can apply the recommendations, or we can agree a bounded optimization task and repeat the relevant experiments. We do not promise to remove every limitation within a fixed package.
Can we reuse the scenarios for later releases?
Prepared scenarios can support engineer-led repeat checks when the application and data remain compatible. We review changes before comparing results. Source handover, permanent panel deployment, ongoing dashboard access and platform support are separate contract terms.
How are scope, cost and timing agreed?
We estimate after reviewing the environment, scenario complexity, available data and monitoring. Infrastructure rental, a new test environment, monitoring setup, distributed generators, long tests and unusual protocols are assessed separately. Engineering hours are not the same as test duration or calendar delivery time.
Do you run tests against the live store?
We agree the test environment first. Any production test needs explicit authorization, monitoring and stop conditions, including controls for payments, orders and external services.