Virtual-user limits per plan
Limits are enforced in the product, not just printed on the pricing page. Solo Pro runs up to 1,000 virtual users, Team up to 10,000 and Enterprise up to 30,000 per run. The Free plan does not include load testing. A run that asks for more than its cap is refused with the cap named, not silently reduced.
Building a profile
- From a recording: the flow becomes the scenario; you set ramp, duration and think time.
- From intent: describe the traffic ("a Black Friday morning: 5x normal, 70% browsing, 30% checkout, ramp over 10 minutes") and get a reviewable, editable load configuration. The description is turned into a configuration by a local model; you approve the configuration before anything runs.
- Thread groups, timers and assertions follow JMeter semantics, so a load engineer's existing mental model carries over.
Reading the results
Averages hide the users who had a bad time. The live dashboard shows P50, P95, P99 and P99.9 latency, throughput, error rate and an Apdex score against the threshold you set. Baselines let you compare a run against the last release and fail a gate on a regression.
Export and safety
- Export to k6, JMeter or Locust and run the same profile from your own infrastructure.
- Target safety: on cloud tenants, private, loopback, link-local and cloud-metadata addresses are refused as targets. A load test is real traffic, so point it at a system you own and tell the people who operate it.
Questions people ask about this
- Can I distribute load across regions?
- Not from the cloud tenant today; runs originate from the Mumbai region. For geographically distributed load, export to k6 or Locust and run from your own nodes.
Source: /documentation/load-testing-basics, updated 2026-09-16. Answers are checked against the shipped product on that date.
Found something out of date? The people who build the module answer the contact form on the home page, and corrections to this guide are dated above. Tell us.