# What is load testing? Source: https://www.plutonapps.com/resources/what-is-load-testing Published 2026-09-30, updated 2026-10-24, sources checked 2026-10-24. By Irfan Habib (https://www.plutonapps.com/authors/irfan-habib). **Load testing:** Load testing is running an application under a realistic, simulated volume of users or requests to measure how it performs: response times, error rates and where it slows down. A stress test pushes beyond expected load to find the breaking point. Both are run on a production-like environment before a launch or a campaign, not discovered during one. Also known as: Performance testing. "Will it cope if we get featured?" is a question with a measurable answer. This is how you get it. ## What can load testing tell you before a launch? A prototype has never had more than a few people on it at once. Launches, press and waitlists do not ramp gently: they arrive at once. Load testing tells you in advance whether the database, the queue and the third-party limits hold, and which one gives out first. ## How do load, stress, spike and soak tests differ? They differ in the traffic they send. A load test sends expected traffic to confirm normal performance, a stress test goes beyond it to find the breaking point, a spike test sends a sudden surge like a launch, and a soak test holds steady traffic for hours to find leaks and slow drift. - Load test: expected traffic, to confirm normal performance. - Stress test: beyond expected traffic, to find the breaking point. - Spike test: a sudden surge, like a launch. - Soak test: steady traffic for hours, to find leaks and slow drift. > **What we see in practice** [Ripply](https://www.plutonapps.com/work/ripply), a viral waitlist platform, had its queue stress-tested with 25,000 synthetic waitlist entries, with zero queue collisions and zero duplicate rewards. Where no load test has been run, as on Bell so far, our case studies say so rather than quote a number. ## How is a load test shaped and run? A load test ramps virtual users up gradually, holds them at the expected level, then ramps down. Grafana's k6 guide suggests a ramp-up of about 5 to 15 percent of the test's length and a hold at least five times longer than the ramp-up. Its example ramps to 100 users over five minutes and holds for thirty. k6 recommends starting with a smoke test: a few users for a short time, to check the script works and the system responds. Then run the average-load test, and only then stress, spike or soak patterns. Watch for response times creeping up as load rises, and for stable performance and resource use while it holds. ## How do you load test a Lovable and Supabase app safely? Test a staging environment rather than production, script the journeys real users take at launch, expect the database to give out first, and check the limits of outside services, such as email and payment providers, before sending them test traffic. The list below explains why each step matters. - Test a [staging environment](https://www.plutonapps.com/resources/what-is-a-staging-environment), not production, so test traffic never reaches real customers or their data. - Script the journeys real users take at launch, such as sign-up and the core action, not just the home page. - Expect the database to give out first: slow queries without a [database index](https://www.plutonapps.com/resources/what-is-a-database-index) are a frequent cause. - Check the limits of outside services, such as email and payment providers, before sending them test traffic. The common mistake is testing a static page and calling the app ready. A home page served from a cache says little about sign-ups writing to the database at the same moment: the hard part is the database, the queue and the integrations behind it. If a launch is close and nothing has been tested, our [vibe coding rescue](https://www.plutonapps.com/services/vibe-coding-rescue) covers it. ## Frequently asked questions ### What is the difference between load testing and stress testing? Load testing checks performance at the traffic you expect. Stress testing deliberately exceeds it to see where and how the system fails. Both belong on a production-like environment before a launch. Ripply's queue, for example, was stress-tested with 25,000 synthetic waitlist entries. ### How long should a load test run? Grafana's k6 guide says average-load tests typically run 5 to 60 minutes, with a gradual ramp-up and a hold at least five times longer than the ramp. Soak tests run for hours, to find leaks and slow drift. A spike test applies a sudden surge for a few minutes. ### What tools are used for load testing? Grafana k6 is one option: a script sets how many virtual users to run and for how long, such as ramping to 100 users and holding for thirty minutes. Whichever tool you choose, start with a small smoke test before larger runs. ## Read next - [The Ripply case study: 25,000 synthetic entries, zero duplicate rewards](https://www.plutonapps.com/work/ripply) ## Sources - [Grafana k6 documentation: load testing](https://grafana.com/docs/k6/latest/testing-guides/test-types/load-testing/) - [Microsoft Azure Well-Architected Framework: Architecture strategies for performance testing](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/performance-test) - [Grafana k6 documentation: Load test types](https://grafana.com/docs/k6/latest/testing-guides/test-types/)