Key takeaways
- Test against the load you expect after growth, not the load you have today, so there is time to fix what breaks.
- A SaaS test needs a tenant model: one large tenant can slow everyone else even when the average looks fine.
- Gate releases with thresholds and rerun the same test on a schedule, so a regression shows up as a failed run.
An earlier version of this post was written as a case study of an unnamed SaaS company, with before and after figures and a survey statistic. None of it could be verified, so it has been removed. What follows is a practical plan for load testing a SaaS platform that is growing, with the numbers marked as examples.
How do you load test a SaaS platform?
Define a target load from your projected growth, script the journeys that real customers run, shape the traffic like your tenant base, run baseline, stress, spike and soak tests from the regions your customers are in, and fail the build when a threshold is breached. Then repeat on a schedule, because the system changes with every release.
What load should a SaaS test target?
Start from today’s peak and the growth you expect over the next planning period. As an illustration, suppose peak traffic today is 400 requests per second and you expect to triple it. A test at 1,200 requests per second shows whether the architecture holds at that size, and a stress run above it shows where it breaks first. Finding that limit while it is still a plan is cheaper than finding it during a customer onboarding.
Use real traffic numbers from your own monitoring for the starting point, and keep a record of which numbers were measured and which were forecast.
How do you model tenants?
SaaS traffic is rarely uniform. A few large tenants often produce much of the load, and a single heavy tenant can use shared database connections, queues or caches that other tenants also need. Build that skew into the test.
A noisy-neighbour test runs one heavy tenant and a normal background of others at the same time, then checks the latency of the others on its own. In k6 you can tag requests by tenant type and put a threshold on one tag:
import http from 'k6/http';
export const options = {
scenarios: {
heavy_tenant: {
executor: 'constant-arrival-rate',
rate: 100, timeUnit: '1s', duration: '10m',
preAllocatedVUs: 200, maxVUs: 400,
exec: 'heavy',
},
other_tenants: {
executor: 'constant-arrival-rate',
rate: 20, timeUnit: '1s', duration: '10m',
preAllocatedVUs: 50, maxVUs: 100,
exec: 'regular',
},
},
thresholds: {
'http_req_duration{tenant:regular}': ['p(95)<800'], // example limit, set your own
},
};
const BASE = 'https://staging.example.com'; // your own environment
export function heavy() {
http.get(`${BASE}/api/reports`, { tags: { tenant: 'heavy' } });
}
export function regular() {
http.get(`${BASE}/api/dashboard`, { tags: { tenant: 'regular' } });
}If the regular tenants slow down when the heavy one runs, you have found isolation work that no average would have shown. The guide to load testing multi-tenant SaaS applications goes deeper on this.
Which test types does a SaaS platform need?
Use four runs, each answering a different question.
| Test | Question it answers | Typical shape |
|---|---|---|
| Baseline | What does normal load look like on this build? | Expected peak, steady |
| Stress | Where does it break first? | Ramp past the target until errors or latency bend |
| Spike | Can it absorb a sudden jump, such as a launch email? | Sharp rise, short hold |
| Soak | Does it stay stable for hours? | Near-peak load, long run |
The differences are covered in load testing versus stress testing, spike testing and endurance and soak testing. Whether autoscaling reacts in time is its own question, covered in validating infrastructure auto-scaling.
Why test from several regions?
Customers in Europe, Asia and the Americas reach your platform over different paths, and a single-region test hides regional CDN, routing and rate-limit problems. Spread the load in proportions that match where your customers are. How multi-region deployment changes load testing results covers the effects in more detail.
Is an API load test enough for a SaaS product?
An HTTP-level test does not run your front-end JavaScript, so it cannot see client-side errors, slow third-party scripts or a broken sign-in redirect. Treat load tests as the backend and API layer, and add a small number of browser checks for the key journeys, run on a schedule from several locations rather than at full load. Browser-level runs cost far more resources per simulated user, which is why they stay few.
How do you keep SaaS performance from regressing?
Put the test in the pipeline with thresholds, for example p95 latency and error rate, so a release that breaks them fails the build. Then schedule the same test to run nightly or weekly and compare each run with a baseline. Use percentiles, not averages, because the slowest requests are the ones customers complain about: see why percentiles beat averages.
Running it with LoadFocus
According to loadfocus.com/load-testing (read 2026-10-23), LoadFocus runs load tests from 25 cloud regions, accepts JMeter and k6 scripts, supports pass/fail thresholds, a GitHub Action that can block a deploy, a Jenkins plugin, scheduled runs and baseline comparison, and provides AI analysis of response times, error rates, throughput and percentiles. The free plan runs up to 10 virtual users and paid plans scale from 250 to 20,000 concurrent virtual users per test, so check your target against that range. See the load testing page and the k6 load testing page.
Frequently Asked Questions
How is SaaS load testing different from testing a single-tenant application?
You need a tenant model. Shared databases, queues and caches mean one tenant’s behaviour can affect others, so a SaaS test runs uneven tenant traffic and checks the quiet tenants separately.
What load profile should we use?
Start with the expected peak after growth for a baseline, add a stress ramp beyond it, a spike for launches and a long soak near peak. Base the numbers on your own traffic data.
How often should we run load tests?
On every release candidate for a short gate, and on a schedule for the longer runs. A test that only runs before big launches misses the regression introduced three releases earlier.
Can AI analysis replace reading the results?
It speeds up reading them by summarising percentiles, errors and likely bottlenecks, but you still decide whether a finding matters for your customers and verify it against the system.
Sources
- Grafana k6 documentation, scenarios, executors and thresholds (grafana.com/docs/k6, read 2026-10-23)
- loadfocus.com/load-testing and /k6-load-testing (read 2026-10-23)
Published with PostNext
