Load testing – do you know where your service breaks?
A load test simulates many concurrent users to show where a service starts slowing down or breaking – before real visitors do it for you. You scope it by deriving realistic load scenarios from the business plan, setting targets for response time and error rate, and weighing the test's cost against what downtime during launch would cost.
A launch, a campaign, or a seasonal peak can multiply the traffic to your service many times over in a matter of minutes. The question isn’t whether the system handles an ordinary Tuesday, but whether it handles the moment when everyone shows up at once. A load test answers that question in advance – instead of letting reality answer it for you, in front of your customers.
Realistic load scenarios from the business plan
A load test is only as good as the scenario it’s built on. Throwing random traffic at a service tells you little; what gives real answers is mimicking what an actual peak looks like. And that picture comes from the business plan, not from the tech department.
Start from the upcoming event. Are you sending a newsletter to the whole list at nine o’clock? Then a large share of the traffic arrives in a spike right at that moment, not spread evenly. Running a sale? Then it’s not just the number of visitors that rises, but also the share who add to cart and check out at the same time – the heaviest operations. A realistic model accounts for how many people arrive, how fast they arrive, and what they actually do.
A concrete example: an online store expects 5,000 visitors in the first hour of a campaign, of whom maybe 500 reach checkout at roughly the same time. You don’t test “5,000 visits spread evenly over an hour” for that – you test a spike where hundreds of purchase flows, the most resource-intensive part, run in parallel. That’s where the system is truly put to the test.
The metrics that matter
When the test runs, three metrics count, each with a reasonable target.
| Metric | Reasonable target |
|---|---|
| Response time (slowest requests) | Pages and actions respond quickly even under full load, not just on average |
| Error rate | Near-zero failed requests during the planned peak |
| Throughput | The system handles the expected peak with margin to spare |
The most important advice: look at the slowest requests, not just the average. An average can look fine while every twentieth customer still gets a page that takes ten seconds – and those are the customers who leave. Set targets based on what users tolerate and what the business requires, not on whatever happens to be easy to hit.
What the test costs versus downtime
The question that decides whether a load test is worth the money isn’t what the test costs, but what a failure would cost.
A load test is typically a contained effort of a few days to about a week, depending on how complex the service is and how many scenarios need to run. Weigh that against what’s at stake: a service that’s down during the launch hour means lost sales at the exact moment everything was building toward, plus trust that’s hard to win back once customers have hit error messages. A campaign you paid to drive traffic to goes to waste if the page won’t load.
In that light, the test is cheap insurance. The results also show where the bottlenecks are – often in the database or in capacity that was sized too conservatively – so they can be fixed calmly before launch. You optimize the weakest points, scale up where needed, and test again until the margin is reassuring.
The difference from a standard performance test
Load testing is sometimes confused with “testing that the page is fast,” but they’re two different things. A standard performance test measures how fast a page loads for one visitor – important, but it says nothing about what happens when a thousand arrive at once. A page can load lightning-fast for you alone and still buckle completely under pressure, because it’s the shared resources – the database, the server, external services – that become the bottleneck once many people use them in parallel.
The load test is specifically about concurrency: how the system behaves when load is applied from many directions at once. That’s why the two complement each other. A fast response for a single user is a prerequisite; proving the response stays fast even when everyone is in at once is what the load test exists to do. Confusing the two means believing you’ve prepared for the peak when you’ve only measured an ordinary day.
Building a service that holds up under pressure is part of our services, and load testing naturally belongs late in a project, just before launch. Want to find out whether your upcoming peak is tested for? Get in touch and we’ll go through the scenario together.
Frequently asked questions
What is a load test?
A load test simulates many concurrent users against your service to see how it behaves under pressure. You ramp up artificial traffic step by step and measure when response times start rising, when errors appear, and where the system finally gives up. The goal is to find the limits in a controlled setting instead of discovering them when real customers try to check out at the same time.
When do I need to load test?
Mainly when an event could multiply your everyday traffic many times over: a launch, a campaign, a sale, or a seasonal peak. If your normal traffic is steady and well under your capacity ceiling, the risk is smaller. But as soon as you expect a traffic spike where many visitors arrive at once, a test is cheap insurance against that exact moment turning into a failure.
Which metrics matter most in a load test?
Response time (how long the user waits), error rate (the share of requests that fail), and throughput (how many requests the system handles per second). Pay special attention to the response time for the slowest requests, not just the average – those are what determine whether individual customers get an unusable experience. Set realistic targets based on what users tolerate and what the business requires.
What does a load test cost?
It depends on how complex the service is and how many scenarios need testing, but it's typically a contained effort of a few days to about a week. The relevant comparison isn't the cost in kronor itself, but the cost of downtime during the exact peak you prepared for – lost sales, lost trust, and a failed launch usually outweigh the price of the test by a wide margin.
What do I do with the results of a load test?
The results show where the bottlenecks are – often in the database, a specific service, or capacity that was sized too conservatively. From there, you fix the weakest points, optimize or scale up, and test again. The point is to run that loop calmly before launch, so you know the service holds up before the real pressure hits.