A load test is a controlled attempt to break your system.
Controlled, because you choose the environment, the scenario, and the moment. Not whatever traffic happens to show up. We raise the traffic until the system goes down. That's an outage on your terms, and it's the only kind that shows where the real limit is.
In this guide
Step by step
From the goal and the scenario, through ramp-up and the hold at peak, to a controlled encounter with the limit.
What we need from you
An environment, test data, access, a time window, and someone who'll pick up the phone during the run. Every gap has a plan B.
What you get at the end
A prioritized diagnosis and the same test after every fix, until the system reaches the goal.
The mechanics
We simulate traffic, raise the load, and watch the numbers.
"We'll see how it behaves in production" is a load test too, just with no scenario, no measurement, and no stop button. The customers who happen to hit the outage pay for it, and you still get no result, because nobody was measuring. In a controlled test, the traffic is the same, but you decide how much and when.
We simulate traffic
Virtual users move through the system along the same paths as real ones: they log in, search, add to cart, pay. The system receives the same requests it would get from real users.
We raise the load
Traffic grows according to the profile set in the scenario: gradually, in waves, or all at once, whatever your real peak looks like.
We watch the numbers
The whole time, we measure how the system is holding up: response times, errors, resource usage. Response times climb and resources run out before the first user-visible error.
Types of tests
The type of test is the shape of the traffic.
Under the hood, the mechanics are always the same. What differs is the shape of the traffic we send, and each shape answers a different question about your system. In everyday use, "load test" is often the name for all of them. Here it means the first of these shapes.
Planned traffic(load test)
Can we handle what we're planning?
Traffic grows gradually to the level you expect for a campaign, a launch, or peak season, and stays there long enough that the result isn't a fluke. The answer is yes or no. And if it's no, you know exactly how far short you fall.
Finding the limit(stress test)
Where exactly does the system break?
We push traffic past what you planned for until the first errors appear. The result is two concrete things: the traffic level at which the system stops responding correctly, and which component gave way first.
Sudden surge(spike test)
What happens when everyone shows up at once?
Instead of a gentle ramp, traffic jumps to its peak in a matter of seconds, like after a newsletter goes out or an ad airs. We measure how many requests the system serves, how many it rejects, and how fast response times return to normal.
Endurance run(soak test)
Can it hold up all day, not just for fifteen minutes?
Moderate traffic held for hours. A memory leak, queues that keep growing, database connections running out. These failures don't come from a single peak. They build up over hours of operation. A short test won't show them.
What we measure
Throughput, response times, errors, resource usage.
Requests per second
How much work the system accepts every second. During the run, we raise the traffic and watch how long this number keeps up. The moment it stops growing, even as traffic keeps rising, is the first sign of the limit.
Response time percentiles
An average hides the slowest responses, so we look at percentiles. p95 means 95 out of 100 requests finished within this time and 5 waited longer. p99 is the slowest 1 in 100. One page view is dozens of requests, so roughly every third user hits that slowest 1 in 100.
Errors
The share of requests that got no response or a wrong one. It stays near zero for a long time, then jumps right at the limit. That's why it's one of the clearest signs that we've just found it.
Resource usage
CPU, memory, the database connection pool. Something always runs out first. The test shows you which. It's usually the first item on the list of fixes.
The numbers in this section are illustrative. They show how the mechanism works and don't come from any specific test.
Step by step
Traffic doesn't come out of nowhere.
The run itself, the part where traffic flows, is only the middle of the process. Preparation comes before it. Analysis comes after, and that's the part that matters most.
Before traffic flows
01
The test goal
We start with a number. How much traffic does the system need to handle? Last season's peak times two? The traffic from the campaign you're planning? That number becomes the goal of the test. Without it, the result has no reference point and there's no way to know when to stop.
02
System knowledge
We gather the raw material for the scenario: API documentation, a description of user journeys, a traffic recording. You don't need all of it. From what you have, we assemble a picture of the system and fill it in by talking to someone who knows it.
03
Realistic scenarios
Real users don't refresh a single page. They log in, search, come back, abandon carts. The scenario reproduces those behaviors and their proportions, because a system that serves thousands of home page views may not survive a few dozen simultaneous writes to the database.
04
Test data
Accounts, products, orders at real-world scale. On an empty database, queries run faster than in production, so the result comes out inflated. We prepare the data ourselves. All we need from you is a sense of what the real data looks like.
The run itself
Phase 01
Ramp-up
First, a few minutes at low traffic. We check that the scenario runs end to end, the data works, and our requests show up in your logs; along the way the cache warms up, so a cold start doesn't skew the measurement. Then traffic grows gradually, following the profile from the scenario. The ramp is where you learn the most: at what traffic level response times start to climb, what happens to the database, and which resource runs out first.
Phase 02
Hold
We hold the target level long enough to rule out chance. A system that survives the peak for a moment is not the same as a system that holds it steady. This is the phase that settles it.
Phase 03
Limit
If the goal is to find the limit, we go higher, past the plan, until the first errors appear. It's a controlled outage. We know when it happened, at what traffic, and what gave way first. The same limit found in production means downtime for your customers.
Throughout the run we watch the metrics live, the same numbers you've already seen on this page. If anything looks off, the test can be stopped with one click.
After the run: the loop
01
Results analysis
We put our measurements side by side with your own metrics: what was visible from outside and what was happening inside at the same moment. That comparison shows what broke and why.
02
Prioritized diagnosis
You get a list of bottlenecks, starting with the most painful. For each one: what we measured, what it causes, and where to start fixing.
03
Fix and rerun
Your team makes the fix, because it's your code and your infrastructure. Then we run exactly the same test again and compare the results before and after. The loop keeps going until the system reaches the goal set at the start. This is what that loop looks like.
What's behind the traffic
On our end
Traffic is generated on scalable cloud machines, not on a single laptop. It comes from many addresses at once, like a real crowd, and we adjust its volume mid-run, second by second, at exactly the rate we set. We place the machines where the goal requires: close to your system when we measure the system itself, or farther away when we also want to see network overhead. The same machines record every response from the system: time, status code, error message. After the run, we build the report from that.
On your end
An environment as close to production as possible (the list below spells out what that means). Plus application and database logs and metrics, so we can look inside when all that's visible from outside is the symptom. And network bandwidth that won't choke the test before it reaches the system.
How it connects
A single agreed-on connection links the two sides: our addresses on your allowlist, the address of the environment, and a time window. Traffic comes in from outside, the same way customer traffic does.
The whole run is described in the scenario, which you read before we start. This is what a scenario looks like.
On your end
What to prepare for a result you can trust.
A load test is a collaboration. The environment, the data, access, and someone's attention during the run. These are what separate a result you can trust from guesswork. For every item, we say what to do if you don't happen to have it.
- 01
Environment
Where the traffic will go: a separate test or staging environment, as close to production as possible, meaning the same database, the same limits, similar capacity. The closer it is to production, the less mental math the result needs. An environment with half the capacity won't give you a straight answer about production.
Don't have it?
Only have production? It can be done. A test in an overnight window, with a more cautious profile and a way to stop instantly. The trade-off: we have less room to hunt for the limit, but the environment is the real thing. We talk it through openly before we start.
- 02
Test data
Accounts you can log in to, products you can buy, order history at a realistic scale. A query without an index runs in milliseconds on a few hundred records; on a million of the same records it can take seconds. A test on an empty database won't show that difference.
Don't have it?
We'll generate the data with you. All we need is an idea of what the real data looks like: how much of what, and in what proportions. Whether to delete or keep the data after the test is something we agree on up front.
- 03
System description
API documentation, a specification, a traffic recording: anything that shows where users go and how they talk to the system. That's what the scenario is built from, and you then read and approve it. The better the material, the less guesswork in the scenario.
Don't have it?
We fill the gaps by talking to someone who knows the system and by recording a real session. Missing documentation slows things down but doesn't stop them.
- 04
Time window
An agreed date for the run: a slot when test traffic gets in nobody's way and nobody deploys changes mid-run. A deployment mid-test invalidates the result, because there's no telling what we measured: the system before the change or after it.
Don't have it?
Busy calendar? We fit the window around your schedule, outside business hours if needed.
- 05
Monitoring on your end
Access to application and database metrics and logs during the test, or a person on your side watching them. Our measurements show how the system responds from outside. Your metrics show why. Only together do they give you the cause, not just the symptom.
Don't have it?
We'll tell you what to turn on. Most hosting providers show basic metrics in their dashboard; you just need to open it.
- 06
Consent and security
Confirmation that the system is yours or that you have the owner's consent; our addresses on your allowlist; a heads-up to your hosting or CDN provider when their terms require it. A provider that wasn't told may classify the test as an attack and cut off the traffic halfway through the run, which invalidates the result.
Don't have it?
Not sure what your hosting provider will say? We'll check the terms and limits together before anything starts.
- 07
A point of contact
One person on your side who knows the system, or knows who does, and is reachable during the test window. Questions come up at specific moments: while building the scenario and during the run. Quick answers keep things moving.
Don't have it?
It doesn't have to be a developer. Anyone who can quickly connect us with the right people will do.
- 08
Someone to make fixes
A team, yours or one you point us to, that can make changes after the diagnosis. The test makes the most sense when someone closes the loop: test, fix, the same test again. Without fixes, all that's left is a list of known problems, and the system's limit stays where it was.
Don't have it?
The diagnosis says precisely what and where, and when it's time to implement the fixes, we can sit down with your team and walk through them.
- 09
External integrations
Payments, email and SMS delivery, partner APIs. Under heavy traffic, these connections have to be stubbed out: we put in stubs that respond like the real provider but send nothing and cost nothing. Providers' sandboxes can't handle that kind of traffic, and their production systems should never see it.
Don't have it?
Not sure which external services your system calls? We build the list of integrations from the system description and the traffic recording, and we prepare the stubs along with the scenario.
Half of this list usually takes shape on the first call. Gaps are a normal starting point, not an obstacle. Let's talk.
Questions and concerns
What everyone asks the first time they hear about this.
How is a load test different from a performance test?
The line between them is blurry, but a performance test usually asks "how fast?" and a load test asks "how many at once?" The first measures the time of a single operation; the second checks what happens to that time when operations pile in. One without the other says little, which is why we look at both in a load test anyway.
Can the test break something?
It can. That's exactly why we keep it under control: an agreed environment, an agreed window, a scenario you read before we start, and the option to stop at any moment. Besides, an outage in the test environment is a valuable result: it shows the limit before production finds it.
How many virtual users do we need?
As many as your goal requires. The starting point is the traffic the system needs to handle: a historical peak, a campaign plan, a seasonal forecast. Plus headroom for finding the limit. The number of users alone says little; we derive it from the target traffic rate and the pace at which real people click. That number comes out of the conversation about the goal.
Does a test environment tell you anything about production?
Yes, provided the environment is similar to production. Then the result carries over directly. The bigger the difference, the more interpretation it takes, which is why we write the differences down before the test and account for them in the diagnosis instead of pretending they don't exist.
Is our customers' data safe?
The test works on test data, not customer data: accounts and records prepared specifically for the run. Traffic goes to the environment you point us to, and the system and its data stay with you. We see the system's responses and metrics. We have no access to the contents of your database.
What if the result is bad?
That's what the test is for. A "bad result" means we found the limit, plus a prioritized list of causes. After your fix, the same test runs again and shows how far the limit moved. From production, the same information arrives in the middle of an outage, in front of your customers.
The remaining questions are usually about your specific system. We answer those in a call.
Now you know how it works. One question left: your system.
This page answers "What is a load test?" The answer to "How much can our system take?" depends on your traffic, your schedule, and your goal, so we work it out in a call.
30 minutes · online · free