Azure Load Testing: a review of Microsoft's service

Azure Load Testing is Microsoft’s managed service for running JMeter and Locust tests at scale from Azure, billed per virtual user hour. It is a strong fit when the system you test runs on Azure, because it can pull server metrics from Azure Monitor and reach private endpoints inside a virtual network. Teams that write k6 scripts, have no Azure subscription or test from outside Azure regions will find other services simpler.

We have not run Azure Load Testing for this review. The facts come from Microsoft’s documentation and pricing page, checked on 19 October 2026, and the judgements are ours.

What is Azure Load Testing?

It is a fully managed service that runs your load test on Microsoft’s test engines, so you never build or patch load generators. You create a load testing resource in a chosen Azure region, add tests to it and start runs from the portal, the Azure CLI or a pipeline.

The overview page says the application under test can live anywhere: in Azure, on-premises or in another cloud. Microsoft now lists the service inside the Azure App Testing hub, next to Playwright Workspaces; the Locust quickstart creates the resource from that hub (checked on 19 October 2026).

Which test types and tools does it support?

Three ways in: a URL-based quick test, an uploaded JMeter script, or an uploaded Locust script. The docs state plainly that it does not support any other testing framework.

The quick test takes up to five HTTP requests and a target number of virtual users or requests per second. Each engine handles up to 250 virtual users, so 400 users run on two engines with 200 each.

With JMeter, you can use plugins from jmeter-plugins.org or upload your own, and the overview says every protocol JMeter supports works, such as a database connection or a message queue. With Locust, you can add Locust plugins and other Python libraries. Locust’s own documentation points to the service as its hosted option, and our Locust review covers the tool itself. k6, Gatling and Artillery scripts do not run here (checked on 19 October 2026).

How do engines, virtual users and limits work?

You scale a test by adding engine instances. For JMeter the total load is the users in your test plan multiplied by the number of engines; for Locust you set the total users and pick how many engines generate them.

The concepts page gives both formulas, and the service limits page sets the ceilings per region and subscription (checked on 19 October 2026):

• Engine instances per test run: 1 to 400 by default depending on the offer, 400 at most.
• Concurrent engine instances: 5 to 400 by default, up to 1,000 on request.
• Test duration: 3 to 24 hours by default, 24 hours at most.
• Fail criteria: up to 50 per test.
• Retention: server-side metrics 90 days, client-side metrics 365 days, test results and logs 6 months.

Raising a default limit means a support request; nothing goes past the stated maximums.

Can it test private endpoints and generate load from several regions?

Yes to both, with one catch: they do not combine. Multi-region load only works against public endpoints.

By default the engines run in the region of your load testing resource. The multi-region guide lets you pick up to 5 regions per test and split the load between them, and it switches the test to public traffic when you do. For services without a public endpoint, virtual network injection places the engines inside the network that holds the application (checked on 19 October 2026).

What do the results and server metrics show?

The dashboard shows client-side metrics live during the run, such as virtual users, response time and requests per second. For Azure-hosted apps it adds server-side metrics from Azure Monitor, Application Insights and Container insights on the same timeline.

That pairing is the service’s main advantage: you can see the database or container that saturates at the moment response times rise, without wiring up a separate dashboard. The server-side metrics guide lists the steps. Past runs stay comparable side by side, and you can download results for other tools.

How do pass/fail criteria and CI work?

You set fail criteria on client or server metrics, and the run is marked failed when any of them is breached. Pipelines in Azure DevOps, GitHub Actions or any CI tool that can call the Azure CLI can start a test and gate on that result.

Per the fail criteria guide, a criterion is an aggregate of a client metric, such as average response time or error percentage, compared with a threshold, either for the whole test or for one named request. Server metrics need the resource’s managed identity to read them. Auto-stop ends a run when the error rate passes a limit, so a wrong URL does not keep billing. The CI/CD guide covers GitHub Actions and Azure Pipelines (checked on 19 October 2026). Our guide to load test pass/fail criteria explains how to choose the limits.

How much does Azure Load Testing cost?

You pay per virtual user hour (VUH): $0.15 per VUH for the first 10,000 VUH and $0.06 per VUH after that, the same in every region the pricing page lists. Since 1 March 2026 there is also a minimum charge per test run.

The pricing page defines a VUH as virtual users multiplied by minutes, divided by 60, counted every 10 seconds; 1,000 users for 30 minutes is 500 VUH, or $75 at the first-tier rate. The minimum is 10 virtual users per engine for the run’s duration, and at least 10 minutes. A 5-user, 3-hour run on one engine is therefore billed as 30 VUH, not 15 (checked on 19 October 2026).

When should you choose something else?

Choose another option when your scripts, your cloud or your budget point elsewhere.

Our overview of open source load testing tools covers the tools you can run yourself.

Choose LoadFocus, which publishes this site, instead when you want to run JMeter test plans and k6 scripts from 25 cloud regions without an Azure subscription. It does not run Locust, and it runs k6 arrival-rate scenarios with a fixed number of users.

Choose Grafana Cloud k6 or the k6-operator instead when your tests are written for k6, which Azure Load Testing cannot run (checked on 19 October 2026).

Choose self-hosted Locust instead when you already run Kubernetes or spare machines: its distributed mode is free, and you only pay for the hardware.

FAQ

Does Azure Load Testing support k6? No. It runs Apache JMeter and Locust tests, plus URL-based quick tests that it turns into a script for you. k6 scripts need another service or your own infrastructure.

Can I use Azure Load Testing for an app that is not hosted on Azure? Yes. The test engines can target any public endpoint. Server-side metrics are only collected for Azure resources, so for other hosting you read server metrics from your own monitoring.

Is there a free tier? The pricing page lists only per-hour prices for load testing, with a minimum per test run. New Azure accounts get a $200 credit for their first 30 days, according to the same page.

Related reading

• Locust load testing: a review of the Python tool
• Open source load testing tools: six options reviewed
• Load test pass/fail criteria: how to set them
• Locust vs JMeter: Python scripts or JMeter test plans?
• Load testing in GitHub Actions: a practical guide

The technical claims in this article have not been independently reviewed.