az load create \
  --name lt-checkout-prod \
  --resource-group rg-perf-testing \
  --location swedencentral

resource testRun 'Microsoft.LoadTestService/loadTests/tests@2023-04-01-preview' = {
  parent: loadTest
  name: 'checkout-load-200vu'
  properties: {
    loadTestConfig: {
      engineInstances: 4
      splitAllCSVs: true
    }
    testScript: 'checkout-load.jmx'
    environmentVariables: {
      target_host: 'staging.example.com'
      threads: '50'
    }
    passFailCriteria: {
      passFailMetrics: {
        p95: {
          aggregate: 'percentage'
          clientMetric: 'response_time_ms'
          condition: '<'
          value: '1500'
          action: 'continue'
        }
        errorRate: {
          aggregate: 'percentage'
          clientMetric: 'error'
          condition: '<'
          value: '1.0'
          action: 'stop'
        }
      }
    }
  }
}

Server-Side Correlation Is the Killer Feature

The single best reason to use Azure Load Testing over self-hosted runners is the automatic correlation between test client metrics and Azure Monitor server metrics. When you point a test at an App Service or AKS cluster in the same subscription, the test report shows:

• Client-side latency percentiles, throughput, error rate over time
• Server-side CPU, memory, HTTP queue length on the App Service or AKS pods
• Database server CPU, DTU consumption, slow query rate on Azure SQL
• Dependency call latency from Application Insights for each downstream

All on the same time axis, in one report. With self-hosted JMeter you can build the same view in Grafana — but you have to build it. Azure Load Testing makes the correlation the default, which materially reduces the time from "the test failed" to "we know which tier failed first."

Where Azure Load Testing Earns Its Place

Three scenarios where the managed service is straightforwardly the right choice:

1. Azure-resident workloads with limited platform capacity — if the team is small and operates a handful of services on App Service or AKS, running and maintaining a self-hosted JMeter or k6 fleet in another region is not worth the cycles. The managed service eliminates that operational tax
2. Compliance-driven evidence trails — the service produces immutable run artifacts (test definition, results, server-side metrics) tied to the subscription's audit logs. For regulated workloads where load-test evidence is part of the compliance package, this is significantly cleaner than reconstructing reports from a self-hosted Grafana
3. Multi-region traffic generation — testing global services from a single self-hosted region misrepresents real user latency. The managed service spins up generators in any subset of Azure regions in a single test, with no infrastructure setup

Where Self-Hosted Wins

Three scenarios where self-hosted JMeter or k6 remains the better fit:

• Non-Azure or hybrid workloads — if part of the system runs on AWS, GCP, or on-prem, the server-side correlation feature loses much of its value. You will rebuild a multi-cloud Grafana view either way
• Very high VU counts at frequent cadence — engine-minute pricing scales linearly. A team running daily 100k-VU tests will pay more for the managed service than for a self-hosted fleet on spot VMs
• Custom protocols or heavy plugin requirements — the service supports JMeter and k6 with their respective plugin and extension models, but ad-hoc protocol modifications are smoother on a self-hosted runner

Pipeline Integration: Azure DevOps and GitHub Actions

The GitHub Actions integration runs a test on every push to a release branch:

name: load-test
on:
  push:
    branches: [release/*]
jobs:
  load:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUB_ID }}
      - uses: azure/load-testing@v1
        with:
          loadTestConfigFile: 'tests/checkout.yaml'
          loadTestResource: 'lt-checkout-prod'
          resourceGroup: 'rg-perf-testing'

The action submits the test, polls for completion, and exports the run report as a build artifact. The pass/fail criteria defined in the test definition determine whether the workflow succeeds or fails. Plug this into a release-branch protection rule and performance regressions block the release the same way unit-test failures do. We typically wire this into the wider azure devops for enterprise pipeline so customers get one unified set of release gates rather than scattered tooling.

Cost Considerations

Azure Load Testing is billed per virtual user-hour and per engine-minute. As of the 2026 pricing sheet, the service is competitive for tests that run a few times per week at moderate VU counts. The cost model breaks down quickly for two patterns: very high frequency (continuous tests every commit) and very high VU counts (100k+ sustained). For those, self-hosted runners on spot VMs are typically 60-80% cheaper.

The pragmatic approach is to use the managed service for staging and pre-prod release gates (where the developer-experience benefit is highest) and self-host for high-frequency continuous testing in dev environments where cost matters more than convenience.

How Opsio Helps

Opsio operates Azure Load Testing for customers as part of broader azure managed delivery engagements and standalone Opsio's load testing. We design the test resource topology in the right Azure regions, author the JMX or k6 scripts against real user-behaviour data, integrate the runs into Azure DevOps or GitHub workflows, and tune the pass/fail criteria so they reflect the SLOs the business actually cares about. Where customers operate hybrid or multi-cloud workloads, we pair the Azure Load Testing service with self-hosted runners for the non-Azure tiers, so the performance practice stays unified across the estate.

For hands-on delivery, see azure backup for enterprise.

For hands-on delivery, see zero-downtime azure disaster.

For hands-on delivery, see how Opsio delivers azure sentinel.

For hands-on delivery, see azure managed services.

For hands-on delivery, see Opsio's azure infrastructure.

For hands-on delivery in India, see zero-downtime azure managed.