Azure SRE Agent hit GA.
Here's what 35,000 incidents don't tell you.

Updated 2026-10-03: we re-checked this post against Microsoft’s current pricing and run-mode documentation and corrected it. AAU stands for Azure Agent Unit. Always-on pricing (4 AAUs per agent-hour) did not change on April 15; only active flow moved from time-based to token-based metering. The current models are Claude Opus 4.6, GPT 5.3 Codex and GPT 5.2, and the run modes are called Review and Autonomous. Microsoft’s own examples put an investigation at roughly $1–4 of active flow, well below our original $10–60 estimate. We also removed an April 1 “cross-cloud MCP” launch we could not find in Microsoft’s or AWS’s announcements; the verifiable cross-cloud move is AWS DevOps Agent’s built-in Azure support. New since April: a 30-day trial with always-on charges waived.

Between March 10 and April 15 of this year, four things shipped that will reshape on-call rotations for the rest of the decade.

Azure SRE Agent went GA. AWS DevOps Agent went GA three weeks later, with built-in support for investigating Azure workloads. Microsoft added Anthropic as a model provider on April 2. And on April 15, Microsoft switched active-flow billing from time to tokens.

Microsoft published the headline number in its GA announcement: 35,000 incidents mitigated, 1,300 agents deployed, 20,000 engineering hours saved. The slide deck made the rounds. CTOs forwarded it to platform leads with a one-line ask: "Why aren't we doing this?"

Here's the awkward truth nobody is putting on a slide: that 35,000-incident number is Microsoft running Microsoft's services on Microsoft's infrastructure. It's a real result. It is not a benchmark for what your team is going to get on day one.

This is the post we wish someone had handed us in late March. A clear-eyed read of what shipped, what the AAU bill will look like, the four-rung autonomy ladder you actually have to choose from, and a 90-day rollout plan that won't get rolled back by your security team in week three.

1. What actually shipped between March 10 and April 15

Five weeks. Four announcements. Tight enough to forget any of them, big enough that all of them matter.

March 10: Azure SRE Agent GA. Public preview opened at Microsoft Build in May 2025 (Microsoft’s preview announcement). The GA release brought deep context from your source code and tools, built-in Python code execution, persistent memory, and a selectable autonomy level, from recommended actions to automated responses within defined guardrails. The same release announced 1,300 internal agents and the 35,000-incident track record. Ecolab, the cleaning and water-treatment giant, was named as the headline external customer.

March 31: AWS DevOps Agent GA. AWS shipped its own analogue: agent-led investigation that correlates telemetry, code and deployment data from CloudWatch and partner tools into a root cause and a mitigation plan, with its access scoped by IAM roles in an Agent Space. AWS calls it a frontier agent, an autonomous system that runs persistently without constant human oversight, and the GA release added built-in support for investigating Azure workloads. That is the real cross-cloud news of the window: one agent correlating incidents across AWS and Azure.

April 2: A second model provider. Azure SRE Agent had always run on Azure OpenAI. Microsoft added Anthropic as a model provider, with Claude Opus 4.6 as the baseline model. You set the provider per agent, and the agent routes each task to a model within it.

April 15: token-based active flow. Always-on pricing did not change: 4 Azure Agent Units (AAUs) per agent-hour for as long as the agent exists. What changed is active flow, which moved from time-based to token-based metering, with a published AAU-per-million-token rate for each model. Predictable in theory; surprising the first month if you didn't realise what always-on means for a fleet of agents.

Together these aren't four separate news items. They're a single architectural shift: the agent layer is now multi-cloud, metered, and yours to govern.

2. The 35,000-incident dataset everyone is misreading

Read the Microsoft GA blog post twice and you'll notice what's missing. There's no breakdown by incident severity. No mean-time-to-resolution by service tier. No false-positive rate for autonomous actions. The 35,000 number is real. Microsoft is running 1,300 SRE Agent instances inside Microsoft. But the population isn't your population.

The dataset that should drive your boardroom conversation isn't Microsoft's internal one. It's the Ecolab result Microsoft cited in the same announcement.

Ecolab (a global cleaning and water-treatment giant, not a tech company) runs approximately 550 Azure resources in just one of its architectural monoliths, which it calls probably its largest source of notification alerts (Microsoft customer story). After a couple of months on the SRE Agent preview, daily performance alerts in their NOC dropped from 30–40 to under 10 (per Microsoft’s GA announcement). The agent didn't fix most of them. It correlated, classified, and dismissed the duplicates and false positives that the alerting rules couldn't disambiguate.

That is the realistic first-quarter outcome. Not autonomous remediation, but correlated triage. If your incident topology looks anything like Ecolab's (monolith plus a tail of supporting services on Azure SQL, Service Bus, Application Gateway), this is the result you should plan against. If you're running a 200-microservice mesh on AKS with eight different observability vendors, calibrate down. Microsoft's 35,000 is the ceiling for what an extremely experienced SRE Agent operator running on a homogeneous Azure-native estate can extract. Ecolab's 30→10 is the floor, and the more honest baseline.

Microsoft has since raised the internal numbers: in August 2026 it cited more than 3,000 internal services and 1.5 million incidents processed, with up to 50% resolved autonomously. The caveat is unchanged. That is still Microsoft’s services on Microsoft’s infrastructure.

3. The four-rung autonomy ladder you actually have to choose from

Every vendor has its own naming scheme. Azure has Review and Autonomous run modes. AWS calls DevOps Agent a frontier agent. Rootly published a Levels 0–3 maturity model that's becoming the de-facto reference. PagerDuty’s Spring 2026 release introduced its SRE Agent as a Virtual Responder in rosters and escalation policies, with early access to a Fully Autonomous Responder scheduled for H2 2026.

Cut through the marketing and there are four rungs. Every team has to pick which one they're on: per service, per runbook.

Rung 0: Read-only. The agent is tail-following your logs, traces, and metrics. It produces incident summaries, suggests probable causes, drafts runbooks. It cannot push a button. Blast radius: zero. Skipping this rung is how you end up rolled back by audit in week three.

Rung 1: Advised. The agent proposes a specific change: restart this pod, scale this ASG, rotate this cert. A human clicks approve. The action is logged with the agent's reasoning attached. This is where Azure SRE Agent's Review mode lands. Blast radius: one service. Rollback: ≤5 minutes via the same agent.

Rung 2: Approved. The agent autonomously executes from a pre-approved playbook library. Each playbook has been written, reviewed, and signed off by humans. The agent picks which one to run; it cannot improvise. Pre-approved actions: pod restarts, log truncation, expired-cert rotation, deploy rollback to last-good-build. Blast radius: one cluster or one tenant. Rollback: documented, automatic on probe failure.

Rung 3: Guardrailed-autonomous. The agent self-decides and self-executes within hard guardrails: an explicit allowlist of action verbs, blast-radius caps (n pods or n%, whichever is smaller), automatic rollback triggers on a SLO probe, and a kill-switch wired to PagerDuty. AWS pitches DevOps Agent as a frontier agent; Azure calls it Autonomous mode; Rootly calls it Level 3. Practically, you're going to ship one or two runbooks at this rung in 2026, not your whole catalogue.

Check the defaults. In Azure SRE Agent the rung is set by the run mode on each incident response plan and scheduled task. The agent-level fallback is Review, but new response plans and scheduled tasks default to Autonomous. Review mode also gates only Azure infrastructure writes: sending email, posting to Teams or querying external sources proceeds on the agent’s reasoning and your response-plan instructions unless you add agent hooks or tool access policies. Audit both before the first production plan goes live.

The mistake teams make is assuming the rungs are sequential by vendor. They aren't. They're sequential by runbook. You should be running rung 0 globally, rung 1 on your top twenty alerts, rung 2 on three pre-approved playbooks, and rung 3 on exactly one, at least until your audit team has seen a clean quarter.

4. MCP is the real story

MCP support got buried under the GA news, and that's a strategic error. Here's why it matters more than either Azure or AWS GA on its own.

Until now, every "AI for ops" demo has had the same hidden assumption: one cloud, one observability vendor, one CI system. The moment you have three of each (which describes basically every enterprise), the agent has to either (a) be re-trained on every tool's API, or (b) speak a shared protocol.

MCP is option (b), and both hyperscaler agents now speak it. Azure SRE Agent connects to any MCP server, with preconfigured connectors for Datadog, Splunk, New Relic, Dynatrace and Elasticsearch. AWS DevOps Agent reaches custom tools through MCP and exposes its own capabilities through managed MCP and A2A endpoints. PagerDuty’s Spring 2026 release goes a step further: agent-to-agent MCP, so its SRE Agent can work with AWS DevOps Agent and Azure’s SRE agent.

The architectural implication: don't pick a winner among Azure SRE Agent, AWS DevOps Agent, Datadog Bits, or Rootly. Pick the MCP servers your existing tools expose, and let the agent layer commoditise over the next 18 months. The agent that mattered in 2024 is not going to be the agent that matters in 2027. The MCP server you ship for your internal Kubernetes platform might still be there.

5. What the AAU bill will actually look like

The billing model is the conversation your CFO wants you to have. Here's the math nobody at Microsoft will quote you in the demo.

Baseline. Each SRE Agent consumes 4 AAUs per hour as the always-on cost: the cost of keeping the agent provisioned, not the cost of work it does. It bills from creation until the agent is deleted; stopping an agent does not stop the charge. AAUs are priced regionally; Azure’s retail price list has US regions such as East US 2 at $0.10 per AAU, and Sweden Central, UK South and Australia East at $0.11. At $0.10 that's $0.40/hour, $9.60/day, $292/month per agent, all before the agent does anything.

Active flow. On top of always-on, every task is metered in tokens (input, output, cache read and cache write) and converted to AAUs at a per-model rate. Microsoft’s current rate card lists Claude Opus 4.6 at 100 AAUs per million input tokens and 500 per million output tokens, and GPT 5.3 Codex at 35 and 280. Its own worked examples put an incident investigation at about 35 AAUs on Claude Opus 4.6 or 12 on GPT 5.3 Codex, and a full “diagnose and fix” remediation at about 87 or 30. At $0.10 per AAU, that's roughly $1–4 per investigation and $3–9 per full remediation.

Worked example. A team running 10 SRE Agents (one per critical service tier) at always-on, plus 200 incident investigations a month at Microsoft’s example consumption (35.3 AAUs each on Claude Opus 4.6, 11.7 on GPT 5.3 Codex):

• Always-on: 10 × $292 = $2,920/month
• Active flow: 200 × 35.3 AAUs × $0.10 = $706/month on Claude Opus 4.6, or $234/month on GPT 5.3 Codex
• Total: $3,154–3,626/month. Call it $3K–3.6K.

Tractable. The trap is the always-on number scaling with your agent count. Twenty agents = $5,840/mo before you've routed a single page. Fifty = $14,600. Microsoft’s own guidance is that one agent can monitor multiple resources within its scope, and consolidating workloads under fewer agents cuts the always-on line. The monthly limit in Settings → Agent consumption caps active flow only (500 to 1,000,000 AAUs); always-on keeps billing until you delete the agent. Configure the limit the day you go live, not the week after the bill arrives. New customers can also trial up to three agents for 30 days with always-on charges waived; active-flow AAUs still bill.

6. Three failure modes you won't see in the demo

Three risks the marketing won't surface. None of them are deal-breakers; all of them are scope items for your readiness work.

Cognitive drift. Agents rarely fail suddenly; they drift over time. Model versions update. Tool descriptions in MCP change, and Azure SRE Agent discovers MCP tools dynamically: when a connected server adds a tool, the agent picks it up without reconfiguration. The agent's effective behaviour on a runbook in month six is not the agent's behaviour on the runbook in month one. Your governance has to include re-validation of every approved playbook on a calendar: at minimum quarterly, ideally per major model version.

The missing-execution-data gap. The commonest blocker in the agent-readiness reviews we run is telemetry granularity: teams monitor uptime and error rate but not the runtime detail an agent needs to reason about — JVM pressure, GC pauses, Thanos query latency, network path metrics. An agent grounded only in the data it can see produces plausible-sounding but confidently wrong remediations. Audit your tail telemetry before you turn rung 2 on.

Agent washing. Gartner's June 2025 estimate: of the thousands of vendors selling agentic AI, only about 130 are real. Gartner calls the rest of the hype agent washing: existing assistants, RPA and chatbots rebranded without substantial agentic capabilities. The gap between an LLM wrapper around your existing dashboard and a genuine reasoning loop with tool use, memory, and rollback is enormous. Demand a live demo on your data, not a recorded one. If the vendor can't run the demo against a sandbox of your actual stack within two weeks, they're a wrapper.

7. A 90-day rollout that survives an audit

If you're starting from zero today, this is the calendar that gives you a defensible position by the end of Q3, with actual production value at every milestone.

Weeks 1–4: Rung 0, non-prod tier.

• Connect SRE Agent to your dev/staging subscription only.
• Hook MCP servers for: monitoring (Azure Monitor or Datadog), source control (GitHub or Azure DevOps), and your runbook repo (Confluence or Notion). No production write access.
• Use the agent for incident summaries, RCA narratives, and runbook draft generation. Score every output against the human-written post-mortem.
• Exit criteria: 4 consecutive weeks of agent-generated incident summaries with no factual errors against the human-written post-mortem.

Weeks 5–8: Rung 1, advised mode in production.

• Promote SRE Agent to your prod subscription, but only on rung 1: every action is a proposal that requires a human approval click. Set Review mode explicitly on every response plan and scheduled task, since both default to Autonomous.
• Define and ship the audit log: agent reasoning + human reviewer + outcome, immutable, queryable.
• Pick your top three alerting categories (likely: pod evictions, memory pressure, certificate expiry) and run them through the advised flow.
• Exit criteria: 50 advised actions executed, ≥80% reviewer approval rate, zero production incidents caused by agent-proposed actions.

Weeks 9–12: Rung 2, three pre-approved playbooks.

• Pick three playbooks where blast radius is bounded and rollback is well-understood: pod restart on liveness failure, log volume truncation on disk pressure, expired TLS cert rotation.
• Author the playbooks as your team would write them. The agent picks which to run; it does not improvise.
• Wire the kill-switch: any rung-2 execution should be reversible by a single PagerDuty button or az command.
• Exit criteria: 100 rung-2 executions, zero unintended consequences, audit team has reviewed the log and signed off in writing.

By week 13, you have concrete, auditable, FinOps-aware evidence for whether to push to rung 3 on a single allowlisted runbook. That's a conversation you have with data. Most teams who try to skip to rung 3 on day one have it without data, lose the argument, and get rolled back to rung 0.

8. Where this goes by Q4 2026

PagerDuty's Fully Autonomous Responder lands in H2. Anthropic's Claude Code already has a PagerDuty integration; Cursor's IDE-agent ships incident replays. Microsoft and AWS will bring their MCP catalogues to feature parity by KubeCon NA. By Q4, the question won't be "do we have an SRE agent?" Every team will. The question is "what runbooks have we taught it, and who owns the audit log when it does the wrong thing?"

Agentic IT operations is the kind of curve that looks slow until it isn't. The teams who started this work in March 2026 will be running rung 3 on twelve runbooks in 2027 with a clean audit trail. The teams who waited until next quarter will be racing to catch up while their first AAU bill lands.

The takeaway

The Azure SRE Agent GA isn't the endpoint of the agentic-ops story. It's the start. The teams who treat it as a button to press will be back at rung 0 in six months, after a Friday-afternoon incident they can't explain to compliance.

The teams who treat it as a multi-quarter readiness program (autonomy ladder, audit log, AAU caps, allowlisted runbooks) are the ones who'll still be running the agent in production when the H2 features land.

The button is shipping. The program is your design problem.

Azure SRE Agent: quick answers

When did Azure SRE Agent reach general availability?

Azure SRE Agent went GA on March 10, 2026, after a public preview that opened at Microsoft Build in May 2025. The GA release added deep context from your source code and tools, built-in Python code execution, persistent memory, and a choice of autonomy from recommended actions to automated responses within guardrails. Token-based active-flow billing followed on April 15, 2026.

How much does Azure SRE Agent cost?

Two components, both billed in Azure Agent Units (AAUs). Always-on: 4 AAUs per agent-hour for as long as the agent exists — at the $0.10 US list price per AAU that's about $292 per month per agent before it does any work. Active flow: tokens metered at per-model AAU rates; Microsoft's own examples put an incident investigation at roughly 12–35 AAUs, about $1–4. A 10-agent fleet handling 200 investigations a month lands at roughly $3,150–3,630/month; the worked math is in section 5 above. New customers can trial up to three agents for 30 days with always-on charges waived.

Does Azure SRE Agent work with AKS?

Yes. AKS is a first-class target: the agent investigates pod evictions, memory pressure, and rollout failures. Microsoft's integration list has no built-in EKS connector, so AWS resources are reached through an MCP server you connect; AWS DevOps Agent covers the reverse direction with built-in Azure support. The caveat from section 2 applies — the denser your microservice mesh and the more observability vendors in the path, the more you should calibrate expectations toward correlated triage rather than autonomous fixes. If your cluster itself is the problem, that's Kubernetes engineering work, not agent work.

Which AI models does Azure SRE Agent use?

You choose a model provider per agent, Azure OpenAI or Anthropic, and Microsoft routes each task to a model within it. The current rate card lists Claude Opus 4.6, GPT 5.3 Codex and GPT 5.2, each metered at its own AAU-per-million-token rate. On Microsoft's example tasks Claude Opus 4.6 uses about three times the AAUs of GPT 5.3 Codex, so the provider choice matters for cost. Microsoft's own guidance: Opus for complex investigations, where fewer reasoning steps can offset the higher rate, and GPT models for simple, high-volume work such as scheduled compliance checks.

Azure SRE Agent gives you the engine. The autonomy ladder, the runbook allowlist, the approval workflow, and the AAU spend cap are all still your design problem, and getting one of them wrong is how you become the 40% of agentic projects Gartner predicts will be cancelled by 2027. InfraZen runs a 4-week AI-SRE Readiness Engagement: we map your current incident topology, define the rung 1→rung 3 gates against your change-management policy, ship the audit/rollback plumbing, and pilot one allowlisted autonomous runbook in production. Talk to us before your first AAU bill lands.

Related: AI agent sandboxes compared · April 2026 DevOps & SRE recap · Site Reliability Engineering services · The alert fatigue trap · Platform engineering adoption crisis · What is SRE? · DevOps vs SRE vs Platform Engineering