Minimum Usage in Azure App Testing
Load testing is most effective when it closely mirrors real-world usage and when test infrastructure is used efficiently. We recently launched AI-assisted load test authoring which enables mirroring real-world usage. Today, we are taking another step for the efficient use of test infrastructure. Behind every load test run, there is dedicated infrastructure that needs to be provisioned, managed, and deprovisioned. Low-user or short-lived load test runs lead to inefficient use of test infrastructure. To keep the service cost-effective and ensure judicious use of test infrastructure, we are introducing a minimum usage per test run for load tests in Azure App Testing. Effective March 1, 2026, load tests in Azure App Testing will incur a minimum Virtual User Hours (VUH) charge per test run. For each test run, the minimum VUH will be: 10 Virtual Users (VUs) per engine for the test run duration, or 10 VUs per engine for 10 minutes, if the test run duration is less than 10 minutes If your test run already meets or exceeds this minimum usage, this change doesn’t impact you. Also, this change is only for load tests and does not impact Playwright tests in Azure App Testing. How It Works? Let’s make this concrete with a few examples. Example 1: Low-user, long-duration test Configuration: 5 VUs, 1 engine, 3 hours Actual usage: 15 VUH = 5 VUs × 3 hours × 1 engine Minimum usage: 30 VUH = 10 VUs × 3 hours × 1 engine You will be charged for 30 VUH, since the actual usage is below the minimum. Example 2: Low-user, short-duration test Configuration: 5 VUs, 1 engine, 5 minutes Actual usage: 0.83 VUH = 5 VUs × (5 min / 60) Minimum usage: 1.67 VUH = 10 VUs × (10 min / 60) × 1 engine You will be charged for 1.67 VUH, since the actual usage is below the minimum. Example 3: High-user, short-duration test exceeding the minimum Configuration: 500 VUs, 2 engines, 5 minutes Actual usage: 83.34 VUH = 500 VUs × (5 min / 60) x 2 engines Minimum usage: 3.33 VUH = 10 VUs × (10 min / 60) × 2 engines You will be charged for 83.34 VUH, since your usage exceeds the minimum. What should you do? Based on usage patterns we’ve observed, some of your test runs may fall below the minimum VUH and could incur a minimum charge. To avoid surprises, we recommend reviewing your test configurations: Low-user, high-engine tests? Reduce the engine count. Short-duration or low-user tests? Increase the user count or duration for meaningful load testing. Tests above minimum usage? No action needed! A small configuration tweak can often make your tests both more effective and more cost-efficient. Need Help? The pricing page and pricing calculator will soon be updated to reflect these changes. If you have a support plan and need technical assistance, please create a support request in the Azure portal. For questions or feedback, share it with the product team on Developer Community Happy load testing that is real-world and efficient!AI-assisted load test authoring in Azure App Testing
Creating reliable load tests shouldn’t require hours of manual scripting. With AI-assisted load test authoring in Azure App Testing, you can go from a simple browser recording to a production-ready JMeter script in minutes, while staying fully in control of what gets applied. This new experience helps you: Create load tests faster by recording real user journeys directly from the browser Improve script quality automatically with AI-recommended best practices Run more realistic tests that better reflect real user behavior Reduce manual effort without giving up transparency or control Record once. Let AI enhance the script. Using the Azure App Testing browser extension for Edge and Chrome, you can record how users interact with your application. Once uploaded to Azure Load Testing, AI analyzes the recording and suggests improvements you can review and apply with a click. AI helps by: Adding smart labels so scripts and test results are easier to understand Applying think times based on actual user interactions Suggesting correlations for dynamic values to prevent test failures at scale Identifying parameterization opportunities to simulate diverse users and data You can accept, edit, or skip recommendations and still manually fine-tune the script if needed. Run at scale with confidence Once your script is ready, configure load, ramp-up, and duration, and run the test at scale using Azure Load Testing. A JMeter script is generated automatically and can be downloaded for further customization. The result is faster test creation, higher-quality scripts, and more meaningful performance insights. Get started AI-assisted load test authoring is available today in Azure Load Testing. Install the Azure App Testing browser extension, record a user journey, and create realistic load tests with less effort and better results. Learn more about the feature here. Tell us what’s working and what we can improve on developer community or directly from the in-product feedback option. Your feedback helps shape the future of AI-assisted load testing. Happy Load Testing!
Stop Running Runbooks at 3 am: Let Azure SRE Agent Do Your On-Call Grunt Work
Your pager goes off. It's 2:47am. Production is throwing 500 errors. You know the drill - SSH into this, query that, check these metrics, correlate those logs. Twenty minutes later, you're still piecing together what went wrong. Sound familiar? The On-Call Reality Nobody Talks About Every SRE, DevOps engineer, and developer who's carried a pager knows this pain. When incidents hit, you're not solving problems - you're executing runbooks. Copy-paste this query. Check that dashboard. Run these az commands. Connect the dots between five different tools. It's tedious. It's error-prone at 3am. And honestly? It's work that doesn't require human creativity but requires human time. What if an AI agent could do this for you? Enter Azure SRE Agent + Runbook Automation Here's what I built: I gave SRE Agent a simple markdown runbook containing the same diagnostic steps I'd run manually during an incident. The agent executes those steps, collects evidence, and sends me an email with everything I need to take action. No more bouncing between terminals. No more forgetting a step because it's 3am and your brain is foggy. What My Runbook Contains Just the basics any on-call would run: az monitor metrics – CPU, memory, request rates Log Analytics queries – Error patterns, exception details, dependency failures App Insights data – Failed requests, stack traces, correlation IDs az containerapp logs – Revision logs, app configuration That's it. Plain markdown with KQL queries and CLI commands. Nothing fancy. What the Agent Does Reads the runbook from its knowledge base Executes each diagnostic step Collects results and evidence Sends me an email with analysis and findings I wake up to an email that says: "CPU spiked to 92% at 2:45am, triggering connection pool exhaustion. Top exception: SqlException (1,832 occurrences). Errors correlate with traffic spike. Recommend scaling to 5 replicas." All the evidence. All the queries used. All the timestamps. Ready for me to act. How to Set This Up (6 Steps) Here's how you can build this yourself: Step 1: Create SRE Agent Create a new SRE Agent in the Azure portal. No Azure resource groups to configure. If your apps run on Azure, the agent pulls context from the incident itself. If your apps run elsewhere, you don't need Azure resource configuration at all. Step 2: Grant Reader Permission (Optional) If your runbooks execute against Azure resources, assign Reader role to the SRE Agent's managed identity on your subscription. This allows the agent to run az commands and query metrics. Skip this if your runbooks target non-Azure apps. Step 3: Add Your Runbook to SRE Agent's Knowledge base You already have runbooks, they're in your wiki, Confluence, or team docs. Just add them as .md files to the agent's knowledge base. To learn about other ways to link your runbooks to the agent, read this Step 4: Connect Outlook Connect the agent to your Outlook so it can send you the analysis email with findings. Step 5: Create a Subagent Create a subagent with simple instructions like: "You are an expert in triaging and diagnosing incidents. When triggered, search the knowledge base for the relevant runbook, execute the diagnostic steps, collect evidence, and send an email summary with your findings." Assign the tools the agent needs: RunAzCliReadCommands – for az monitor, az containerapp commands QueryLogAnalyticsByWorkspaceId – for KQL queries against Log Analytics QueryAppInsightsByResourceId – for App Insights data SearchMemory – to find the right runbook SendOutlookEmail – to deliver the analysis Step 6: Set Up Incident Trigger Connect your incident management tool - PagerDuty, ServiceNow, or Azure Monitor alerts and setup the incident trigger to the subagent. When an incident fires, the agent kicks off automatically. That's it. Your agentic workflow now looks like this: This Works for Any App, Not Just Azure Here's the thing: SRE Agent is platform agnostic. It's executing your runbooks, whatever they contain. On-prem databases? Add your diagnostic SQL. Custom monitoring stack? Add those API calls. The agent doesn't care where your app runs. It cares about following your runbook and getting you answers. Why This Matters Lower MTTR. By the time you're awake and coherent, the analysis is done. Consistent execution. No missed steps. No "I forgot to check the dependencies" at 4am. Evidence for postmortems. Every query, every result, timestamped and documented. Focus on what matters. Your brain should be deciding what to do not gathering data. The Bottom Line On-call runbook execution is the most common, most tedious, and most automatable part of incident response. It's grunt work that pulls engineers away from the creative problem-solving they were hired for. SRE Agent offloads that work from your plate. You write the runbook once, and the agent executes it every time, faster and more consistently than any human at 3am. Stop running runbooks. Start reviewing results. Try it yourself: Create a markdown runbook with your diagnostic queries and commands, add it to your SRE Agent's knowledge base, and let the agent handle your next incident. Your 3am self will thank you.AI-Powered Performance Testing
Performance testing is critical for delivering reliable, scalable applications. We have been working on AI-driven innovations in Azure Load Testing that will change how you author and analyze load tests. AI-Assisted Authoring of JMeter Scripts Writing high-quality load test scripts has traditionally required deep expertise. From setting correlations and think times to properly parameterizing inputs, it requires significant time and effort. This manual effort slows teams down, especially when they must recreate real-world scenarios under tight deadlines. With our new AI-assisted authoring, that changes. Now you can simply record your application journey, and Azure Load Testing will do the heavy lifting: Record your scenarios using the browser extension AI automatically suggests correlations to handle dynamic values Intelligent parameterization for more realistic test data Smart request labelling to help you organize flows cleanly Recommended think times to match actual user behavior Once refined, a production-ready JMeter script is generated automatically. You can run this script immediately on Azure Load Testing with the scale and reliability you expect. You can create complex, realistic performance tests created in a fraction of the time, even if you’re not a JMeter expert. AI-Powered Actionable Insights Performance tests don’t stop at execution. Real value comes from understanding what happened and knowing what to do next. We have supercharged our insights experience with AI. Insights for Failed Test Runs: When a test fails, the first question is always: why? Now, Azure Load Testing uses AI to automatically analyze test run logs, detect the root cause, and provide clear guidance on what went wrong and how to fix it. Baseline Comparison Insights: Compare any test run against your defined baseline to immediately see what degraded, what improved, and which requests diverged from expected performance. It also helps understand the root cause for performance degradation. Focused Recommendations for Failed Test Criteria: If any of your pass/fail criteria fail, AI surfaces targeted recommendations so you can take corrective action quickly. You get meaningful insights, even when things don’t go as planned. No more staring at graphs trying to figure out what to do next. The Future of Load Testing Is Intelligent With AI assisting script creation and analyzing test outcomes end-to-end, Azure Load Testing now helps teams: Run real world performance tests faster Troubleshoot with confidence Reduce manual debugging The authoring capability will be available in the next couple of weeks. Meanwhile, you can try out AI-powered insights for your load test run to quickly analyze your results. Please share your feedback here. Happy Load Testing!Scaling Azure Functions Python with orjson
Azure Functions now supports ORJSON in the Python worker, giving developers an easy way to boost performance by simply adding the library to their environment. Benchmarks show that ORJSON delivers measurable gains in throughput and latency, with the biggest improvements on small–medium payloads common in real-world workloads. In tests, ORJSON improved throughput by up to 6% on 35 KB payloads and significantly reduced response times under load, while also eliminating dropped requests in high-throughput scenarios. With its Rust-based speed, standards compliance, and drop-in adoption, ORJSON offers a straightforward path to faster, more scalable Python Functions without any code changes.Running a Load Test within a Chaos Experiment
With Azure Chaos Studio and Azure Load Testing, you can simulate both — run a controlled load test while injecting faults into your application or infrastructure to understand how it behaves under stress. Together, they help you find those resiliency blind spots — the cascading failures, retry storms, and degraded dependencies that only appear when your system is both busy and broken. For example: What if your database becomes read-only during peak user traffic? How does your API react if a downstream service starts returning 500s? Can your autoscaling rules recover fast enough? Let’s explore how you can run load tests from Azure Load Testing as part of a chaos experiment. Azure Chaos Studio + Azure Load Testing Integration Azure Chaos Studio has load test actions that let you integrate load testing directly into your chaos experiment flow. From the Chaos Studio fault library, you can find: Start load test (Azure Load Testing) Stop load test (Azure Load Testing) Triggers a load test from your Azure Load Testing resource as part of an experiment step. This means you can now orchestrate a sequence like: Start load test Inject a fault (e.g., shut down VM, throttle network, restart App Service) Observe and measure resiliency Stop the test and analyze metrics Chaos Experiment with Load Test Action Here’s how a typical experiment might look conceptually: Step 1. Define the experiment in Chaos Studio Create a new experiment that targets your application or infrastructure components — for example, an App Service or a SQL Database. Add the Start Load Test (Azure Load Testing) action: This tells Chaos Studio to kick off a load test from Azure Load Testing. Step 2. Add faults to simulate real-world failures You can follow up the load test action with a fault like: CPU pressure on your VM or container Network latency or packet loss injection Service shutdown of a dependent component Step 3. Observe and analyze Once the experiment runs, you can: View load test metrics (like response times, error rates, throughput) in Azure Load Testing View fault outcomes in Chaos Studio Correlate both using Application Insights or Log Analytics This gives a holistic view of performance and resiliency under controlled failure. By combining load and chaos, you can answer: How does latency or failure in one microservice affect end-to-end response times? Do retry policies or circuit breakers behave as expected under load? Does the system self-heal once the fault is removed? What’s the performance impact of failover mechanisms? Conclusion Chaos testing under load helps teams move from confidence to certainty. Azure’s native integration between Chaos Studio and Load Testing makes it easier than ever to build resiliency testing into your CI/CD pipeline — using only Azure-native services. Learn More Azure Chaos Studio documentation Azure Load Testing documentation
Azure Load Test Pricing
H , This is regarding Azure load testing pricing. Please advice. Virtual User Hour (VUH) usage 0 - 10,000 Virtual User Hours - $0.15/VUH10,000+ Virtual User Hours - $0.06/VUH Virtual User Hour (VUH) usage 0 - 10,000 Virtual User Hours - $0.15/VUH10,000+ Virtual User Hours - $0.06/VUH I am trying to understand above pricing. Lets say i want to run a test with 10k users just to login my website. This will max take 10 sec to complete. How will the pricing gets calculated? Regards, Sharukh
