What is load testing?

Load testing checks how your website, app or API behaves under the number of users you expect at your busiest time. We simulate those users with realistic journeys and data, then measure response times, throughput and errors against agreed targets.

How is load testing different from stress, spike and soak testing?

Load testing holds your expected peak. Stress testing keeps adding load past it to find your limit. Spike testing jumps to peak in seconds to check scaling. Soak testing holds steady load for hours to find leaks. Most projects combine load testing with one or two of the others.

When should we run a load test?

Before a launch, a sale or campaign, a migration or an infrastructure change, and after any release that touches key journeys or the database. Teams that release often also run short load checks in their pipeline.

How do you decide how many users to simulate?

From your analytics, server logs and business forecast. We work out concurrent users and requests per second at your busiest hour, then add headroom, usually 25–50%, so you know how much margin you have.

What do you measure during a load test?

Response times at the 90th and 95th percentile, requests per second, error rates and active users for each journey, alongside CPU, memory, database, cache and network metrics from your servers and monitoring tools.

Can you load test APIs and mobile apps, not just websites?

Yes. APIs are tested directly at the request rates your clients send. Mobile apps are load tested through their backend, using the same calls the app makes.

Which load testing tools do you use?

JMeter and k6 most often, plus Gatling, Locust, LoadRunner, NeoLoad and BlazeMeter. For monitoring we use Grafana, Prometheus, New Relic, Datadog and AWS CloudWatch. We can also work in the tools you already have.

Do you test in production or in staging?

Usually in a staging environment sized like production. When nothing else is realistic, we plan production tests carefully: outside busy hours, with agreed limits, monitoring and a clear stop rule.

What do you need from us?

Access to a test environment, your key journeys, any traffic data you have, test accounts and data, and a contact in your development or DevOps team. We sign your NDA before we get access.

How long does a load testing project take?

As a general guide, a focused test of a few key journeys takes two to three weeks from workload model to report. Larger systems, several environments or extra fix-and-retest rounds take longer. You get a timeline after the first call.

What will the load test report include?

Results per journey and load level, the point where response times or errors pass your targets, the bottlenecks found with their root cause, fixes ranked by user impact and effort, and a before-and-after comparison once fixes are retested.

Do you help fix the bottlenecks you find?

We trace each bottleneck to its cause, such as a query, a cache, a configuration setting or a scaling rule, and suggest the fix. Your developers make the change, and we retest to confirm the improvement.

Can load tests run in our CI/CD pipeline?

Yes. We add short k6 or JMeter checks to GitHub Actions, Jenkins, GitLab CI or your own pipeline, with pass/fail budgets for response time and errors, and keep full load tests for major releases.

How much does load testing cost?

It depends on the number of journeys, environments and test rounds. A scoped load test is usually quoted as a fixed price, and ongoing release testing as a monthly plan. Try our cost utility for a first estimate, or ask us for a quote.

Load Testing Services

Find out how your website, app or API holds up at its busiest hour, before your customers do it for you.

We model your real traffic, run it against a production-like environment and watch every layer while the load is on. You get clear numbers against agreed targets, the bottlenecks behind any slowdown, and fixes ranked by how much they matter to users.

Get in touch Plan your load test

Websites, APIs and apps
JMeter, k6, Gatling and more
Bottlenecks traced to the cause
Free one-week POC

What we do

Peak-loadExpected peak Website & web app loadReal user journeys API & microservices loadMobile backends too Database & backend loadWhere slowdowns start Third-party services under loadLimits you don’t control Cloud capacity & autoscalingInfrastructure Launch & campaign readinessFixed dates Load in CI/CDContinuous

[ Why load testing ]

The traffic you planned for can still slow you down

Most slowdowns don’t need record traffic. An ordinary busy hour is enough when it meets a query nobody indexed, a connection pool sized for testing, or a payment provider that throttles you at the wrong moment. Load testing recreates that busy hour on purpose, with realistic users and data, so you can see where response times climb and errors begin while there is still time to fix them.

Need stress, spike or soak testing too? See performance testing services →

Launch with known limits

You know how many users you can serve, and what happens just past that number.

Faster pages at peak

Slow queries, chatty APIs and missing caches found under real load, not guessed.

Right-sized infrastructure

Evidence for how much capacity you need, so you neither overpay nor run short.

No slow creep between releases

A baseline you can rerun, so a new release can’t quietly make things slower.

[ What we test ]

Eight load testing services for the busiest day you expect

From one critical journey before a sale to load checks on every release. Each card lists what we test, when you need it and the problem it prevents.

Peak-load testing

Your busiest hour

We recreate your expected busiest hour, with the right mix of users and actions, and hold it long enough to see how the system settles.

What we test

Workload model built from your analytics or business forecast
Ramp-up, steady hold and ramp-down
Response times at the 90th and 95th percentile, not just averages
Error rate and throughput per journey

When you need it

Before launches, seasonal peaks and any major release.

The problem it preventsA product that passes every test except the one on your busiest day

Website & web app load testing

Browser and protocol

Real user journeys scripted end to end (sign-in, search, cart, checkout, dashboards) with sessions, cookies and dynamic data handled properly.

What we test

Protocol-level scripts for high user counts
Browser-level checks of page rendering under load
Tokens, sessions and CSRF values correlated correctly
Think time and pacing based on real behaviour

When you need it

For any public website, customer portal or SaaS app.

The problem it preventsPages that load fast for one user and time out for a thousand

API & microservices load testing

REST, GraphQL, gRPC

View service

Your APIs under the request rates your apps and partners will actually send. Mobile apps are load tested here, through the same calls the app makes.

What we test

Requests per second and latency per endpoint
Service-to-service calls and timeouts
Authentication and token refresh at volume
Rate limits, retries and back-pressure

When you need it

For mobile backends, public APIs and microservice architectures.

The problem it preventsOne slow service holding up every request behind it. For functional API checks, see API testing.

Database & backend load testing

Queries, pools, caches

View service

Load is where a missing index or an undersized connection pool shows up. We watch the database and backend while traffic is applied.

What we test

Slow queries and locking under concurrent use
Connection pool, thread and queue limits
Cache hit rates, and what happens on a cold cache
Production-sized test data

When you need it

After schema changes and migrations, and as data volumes grow.

The problem it preventsQueries that are fine on a test database and crawl on real data. For large data sets, see volume testing.

Third-party services under load

Payments, sign-in, search

Payment gateways, identity providers and partner APIs have limits of their own. We find out what happens when you reach them.

What we test

Sandbox and rate limits agreed before testing
Mocks for services that can’t take load
Timeouts, retries and fallbacks at peak
Queues and webhooks backing up

When you need it

When key journeys depend on services you don’t control.

The problem it preventsCheckout failing because a provider throttles you at peak

Cloud capacity & autoscaling

AWS, Azure, Google Cloud

View service

We check that the infrastructure you pay for scales when it should, fast enough, and scales back down afterwards.

What we test

Autoscaling rules and warm-up times
CPU, memory and network headroom per tier
Load balancer and CDN behaviour
Capacity needed at each load level

When you need it

Before an infrastructure change, region move or cost review.

The problem it preventsPaying for capacity you don’t need, or missing capacity you do. For the full service, see scalability testing.

Launch & campaign readiness

Sales, drops, go-lives

A focused load test ahead of a date you can’t move: a product launch, a sale, a ticket release or a migration go-live.

What we test

Campaign traffic modelled with your marketing team
Sudden ramp-ups checked with a spike run
Go/no-go report against agreed targets
A watch plan for the day itself

When you need it

A few weeks before the date, so there is time to fix what we find.

The problem it preventsFinding your limit live, in front of every customer

Load testing in CI/CD

Every release

View service

Short, repeatable load tests in your pipeline with performance budgets, so a slowdown is caught on the change that caused it.

What we test

k6 or JMeter checks run from GitHub Actions, Jenkins or GitLab CI
Pass/fail budgets for response time and errors
Trends tracked release to release in Grafana
Full load tests scheduled before major releases

When you need it

When you release often and speed matters to revenue.

The problem it preventsReleases that each get a little slower until users notice

[ Load testing vs other performance tests ]

Load testing answers one question: can you handle the traffic you expect?

The other tests answer different questions, and most projects combine load with one or two of them. On the right is what a load test finding looks like.

Test	Question it answers	Load shape
Load testing This page	Do we meet our targets at expected peak?	Ramp to peak, hold, ramp down
Stress testing	Where is our real limit, and what fails first?	Keep adding load past peak
Spike testing	Do we survive a sudden rush?	Jump to peak in seconds
Soak testing	Do we stay stable for hours?	Steady load for many hours
Scalability testing	What does extra capacity really buy?	Repeat at each capacity step
Volume testing	Do we cope with large amounts of data?	Production-sized data sets

Sample load test findingPeak-load run

Journey: Search → product page → checkout
Load profile: Ramp to 2,000 users over 15 minutes, hold for 45
Targets: 95% of pages under 2 s, errors under 1%
Finding: Checkout passed 2 s at about 1,400 users
Root cause: Unindexed query on order history
Retest: Index added; checkout within target at 2,000 users

Example only. Real reports use your journeys, targets and data.

[ How we work ]

Six steps from workload model to a faster product

Every number in the report traces back to a model you agreed. Every script, result and report belongs to you.

Step 1 of 6
Model the workload

We turn your analytics, logs and business forecast into a model: which journeys, how many users and how fast they arrive.

You getWorkload model
Step 2 of 6
Agree targets and environment

Response time, throughput and error targets agreed with you, and a production-like environment confirmed.

You getLoad test planAgreed targets
Step 3 of 6
Script and prepare data

Scripts for each journey with realistic, varied test data, reviewed with your developers.

You getTest scripts you own
Step 4 of 6
Run with monitoring

A baseline first, then peak and headroom runs, with servers, database and APM watched throughout.

You getResults per load level
Step 5 of 6
Find the bottlenecks

Results matched to server metrics and traces, so each slowdown points to a cause.

You getBottleneck reportFixes ranked by impact
Step 6 of 6
Retest and hand over

We rerun after fixes to prove the gain, and leave the scripts ready for your next release.

You getBefore-and-after reportReusable test suite

Free one-week POCWe model one key journey and run a first load test on it, so you can judge our work first.
Agreed limits, safe runsLoad levels, timings and stop rules agreed with your team and hosting provider before any run.
NDA before accessWe sign your NDA first and use test accounts and test data by default.

[ Tools ]