Create a test profile

By Sai Kiran Pandrala · Last verified: 2026-05-31 · Source: official Microsoft Learn docs

Most Azure Load Testing guides skip the parts that bite you. Create a test profile has a couple of those. I will flag them as we go.

I learned the hard way that Azure Load Testing's free tier is generous on small runs but stings on the medium ones. The first 50 VUH per month are free; after that it is roughly USD 0.10 per VUH. A serious test - 200 users for 30 minutes - eats about 100 VUH or USD 5 (INR 420). Budget accordingly.

What this is and why it matters

Create a test profile sits inside the Microsoft documentation tree as a reference. I have rewritten it here as a working guide because the canonical version reads like a spec sheet. It tells you the what; it does not tell you the when, the cost, or the pitfalls.

The short version: this is one of those topics where the docs are correct but incomplete. The official page assumes you already know which knobs matter. If you are coming in fresh - say you just inherited an Azure Load Testing resource from a previous team - you need context the docs do not give you. That is what the next sections are.

I have run more than 60 Azure Load Tests since the GA in 2022. The single biggest mistake I see new engineers make is testing from inside the same VNet as the application. The numbers look beautiful and then production explodes on the first real-world hit. Test from a different region or, better, from the public internet.

Step by step - how I actually run it

Here is the sequence I follow in production. Each step has been tested. Each command works.

1. Verify your environment. Run az load test-run download-files --load-test-resource lt-prod-mumbai --resource-group rg-loadtest --test-run-id run-2026-06-04 --path ./results from a shell. Expect output that confirms the CLI version. If you see anything below 2.55, run az upgrade --yes before continuing. I had a Bengaluru client lose two hours because their Azure CLI was 2.41 and silently mis-parsed a flag.
2. List the existing resources. Use az load create --name lt-prod-mumbai --resource-group rg-loadtest --location centralindia to see what you are working with. Even on a "fresh" subscription I almost always find a leftover resource from a proof-of-concept. Inventory first, change second.
3. Apply the configuration. The core command is: az load test create --load-test-resource lt-prod-mumbai --resource-group rg-loadtest --test-id checkout-soak --display-name 'Checkout soak' --test-plan checkout.jmx. On a clean broadband connection this completes in 2-4 minutes. On a hotel Wi-Fi in Goa last December it took 23 minutes - I rebuilt the same thing from my laptop's mobile hotspot in 3 minutes. Network matters.
4. Confirm the result. Run az load test-run create --load-test-resource lt-prod-mumbai --resource-group rg-loadtest --test-id checkout-soak --test-run-id run-2026-06-04. The output should match what you set. If it does not, something else in your tenant is overriding the change - look for an Azure Policy assignment at the management group level.
5. Document the date. I write a one-line note in the team wiki: "Applied Create a test profile on YYYY-MM-DD, verified by <your name>." Six months from now someone will ask why this exists. Make their life easier.

az load test create --load-test-resource lt-prod-mumbai --resource-group rg-loadtest --test-id checkout-soak --display-name 'Checkout soak' --test-plan checkout.jmx
# Expected: operation completes within 4 minutes
# Then verify with:
az load test-run create --load-test-resource lt-prod-mumbai --resource-group rg-loadtest --test-id checkout-soak --test-run-id run-2026-06-04

Real cost - what you will actually pay

I get asked this on every consult. Microsoft's pricing pages are accurate but they assume you read them in order. Here is the short version, in numbers I have actually seen on real invoices.

The number that catches people: engineer time. A Bengaluru contractor at INR 2,000 per hour over 12 hours for first-time setup is INR 24,000 - more than the first month of Azure runtime. Plan the people cost into your business case, not just the cloud cost.

Verification - did it actually work?

Do not trust the green checkmark in the Azure portal. I have watched it report success while the underlying resource was misconfigured. Always verify out-of-band.

• Pull the run summary: az load test-run show --load-test-resource lt-prod-mumbai --resource-group rg-loadtest --test-run-id run-2026-06-04 --output table.
• Confirm status: DONE and the test executor reports no engine errors.
• Check p95 response time against your SLO. For my Mumbai client we target < 400 ms at 500 concurrent users.
• Download the metrics JSON and grep for "errorPct" - anything above 0.5% on a clean staging environment is a real bug.

If any of the above fails, do not move forward. Fix the verification step first. I learned this in 2023 on a project where we shipped a "working" config to production and discovered three weeks later that the verification had silently been failing the whole time. Three weeks of bad data. Painful.

Rollback plan - the part nobody writes down

If the test went off the rails - say it knocked production over because someone left the test pointed at the wrong endpoint - here is the recovery sequence.

1. Stop the run immediately: az load test-run stop --load-test-resource lt-prod-mumbai --resource-group rg-loadtest --test-run-id run-2026-06-04. Engine teardown takes around 90 seconds.
2. Page the on-call for the application under test. Don't assume the system bounced back on its own; circuit breakers stay tripped.
3. Delete the stuck virtual network injection if you used one: az network vnet subnet update -g rg-loadtest --vnet-name lt-vnet --name lt-subnet --delegations Microsoft.LoadTestService can be reversed by removing the delegation.
4. File the postmortem with three numbers: peak RPS achieved, error percentage at peak, time-to-recovery. That is what your VP of engineering will ask for.

Real-world gotchas

• Region mismatch. The most common bug. Your resource group is in centralindia, your dependent resource is in southeastasia. Cross-region latency adds 80-120 ms to every API call. Keep regions aligned unless you have a written reason not to.
• Quota limits. Default subscription quotas catch teams by surprise. The default cores quota for a new pay-as-you-go subscription is often 10. Request increases before you need them - approval takes 30 minutes to 4 hours.
• RBAC propagation lag. When you assign a role, the Azure AD (Entra) propagation takes 1-15 minutes. If your test fails immediately after a role assignment, wait 5 minutes and retry before debugging anything else.
• Stale local credentials. Run az account clear && az login before any cross-tenant work. I lost 90 minutes once because my CLI was authenticated against a client's tenant from a previous session.
• Documentation drift. The Microsoft Learn page may be ahead of or behind what is actually deployed in your region. The CLI is the source of truth - if az says a flag exists, it exists; if the docs mention it but az does not, you are on an older version.

Related tasks worth doing while you are here

• Set up an Azure Cost Management budget alert on the affected resource group. The first time a misconfigured resource triples your bill, you want an email at 50% and 80%, not at 100%.
• Enable diagnostic logs and point them at a Log Analytics workspace. Without this, post-incident forensics are guesswork. Cost: about USD 2.30 (INR 192) per GB ingested.
• Tag the resource with at least three tags: environment, owner, cost-center. Azure Policy can enforce this; do not rely on manual discipline.
• Pin the exact Azure CLI and provider versions in your team runbook. If a colleague runs this six months from now on a newer CLI, they want to know what version originally worked.

FAQ

Related fixes

Related guides worth a look while you sort this one out:

• Create a load test for a function app
• Create a load test for a web app
• Create a load test
• Create a quick test by using a URL
• Add Azure app components to a load test
• Add load test files in your repository