TL;DR
Get business pricing on monitors, keyboards and dev gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
AI-assisted incident response is gaining traction as companies face more deployments and on-call pages. Current tools focus mainly on investigation and triage; the conference-demo vision of agents safely fixing production incidents without human oversight remains unproven.
AI-assisted on-call tools are gaining traction as software teams report more deployments and pages, but the systems now being discussed mainly help investigate and triage incidents rather than independently change production. The Pragmatic Engineer’s report, based on interviews with vendors and engineers, says the gap between current practice and conference demonstrations of fully autonomous AI responders remains substantial.
The report describes AI SRE as a loose label for tools that gather incident information, search operational context and help engineers investigate through platforms such as Slack or Teams. Some systems can triage alerts or suppress pages judged unimportant. Whether an agent should also write and deploy a code fix is a separate, disputed question: an incorrect change could worsen an outage.
The publication spoke with Rootly, incident.io and ResolveAI, which make incident-response products, and cites examples of organizations building internal systems. It reports that OpenAI has built an AI SRE bot called Sevbot, and that an ING engineer described work on an in-house AI SRE. These examples indicate activity, but the report does not provide independent performance evaluations of those systems.
To improve investigations, teams commonly let multiple agents examine an incident and have engineers steer the process in chat. A so-called context layer can connect operational knowledge and past incidents. The report also describes checks such as having agents challenge one another’s hypotheses, using different models, and testing systems against past incidents. It says accuracy is difficult to measure and depends on each company and engineering team.
More Pages, Harder Incidents
The business case starts with a reported increase in software changes. The report says many technology companies have at least doubled pull-request frequency over a year as AI coding tools accelerate development. It also cites Rootly data showing pages are up from a year earlier and outside-business-hours pages have nearly doubled. The report does not give the underlying counts or a detailed methodology, so those figures should be read as source-attributed observations, not a universal industry measure.
More changes can mean more opportunities for failures, although deployment volume alone does not establish that AI coding tools caused a rise in incidents. If on-call teams receive more alerts, faster investigation could reduce time spent assembling evidence and help engineers focus on the most consequential problems. The report suggests the eventual goal is fewer unnecessary pages, while warning that the incidents that still reach engineers may be difficult.
There is also a skills concern. If responders rely heavily on automated diagnosis, they may get less practice handling incidents themselves. The report points to incident-response simulations, including training from Uptime Labs, as one way teams could maintain those skills. Whether AI tools reduce workload without weakening operational readiness remains an open question.
Products Worth Considering
Apple iPad Air (2025) 13‑inch Wi‑Fi 256 GB – Space Gray (M3 chip)
Jackery HomePower 1000 Plus v2 Portable Power Station
Amazon Kindle Scribe Colorsoft 64GB (1st Generation)
As an affiliate, we earn on qualifying purchases.
From Stage Demo to On-Call
At Microsoft’s May 2025 BUILD conference, the company demonstrated an Azure SRE Agent responding to an alert, identifying a purported root cause and shipping a fix without waking a human on-call engineer. The report’s author said the demonstration seemed artificial and questioned whether teams would allow an AI to make production decisions without oversight. The report says that, after BUILD, the author heard little about SRE agents until more recent vendor activity and examples from companies.
The term itself is imprecise. Site reliability engineering covers much more than responding to alerts, and the vendors interviewed reportedly did not favor “AI SRE” but said alternatives had not caught on. The report frames today’s products more narrowly as AI-augmented incident response. It also notes that automated alert triage is not entirely new: Meta was operating AI in parts of its systems two years earlier, according to the report.
The author disclosed an investment in incident.io and said they had no other affiliation with the vendors discussed and were not paid to include them. That relationship is relevant when weighing the report’s vendor interviews and product descriptions.
““Incident rate = [Change rate] × [Probability].””
— The Pragmatic Engineer report
Accuracy and Autonomy Still Open
The report does not establish how often AI SRE systems reach a correct diagnosis, shorten outages or reduce pages across a representative group of companies. It says evaluation is difficult because incident histories, systems and acceptable risks differ between teams. Vendor descriptions and examples of internal projects show interest, but do not on their own prove reliable results.
It is also unclear how widely current tools are deployed, what safeguards they use, or how often they are allowed to make changes rather than recommend them. Rootly’s page figures are not accompanied in the supplied report material by raw counts or a comparison methodology. The report’s broader account of rising deployments and incidents should not be taken as proof that AI-generated code caused the reported page increases.
Testing Tools in Real Incidents
The next test is whether teams can show, using their own incident records, that AI-assisted investigation improves response without introducing unsafe changes or obscuring how a system works. Useful evidence would include how often diagnoses are correct, whether responders resolve incidents faster, how many alerts are safely filtered and how performance compares with established procedures.
For now, the report describes a developing category rather than a settled replacement for human on-call engineers. Teams are likely to keep experimenting with chat-based investigations, agent checks and alert triage, while deciding where human approval must remain. The central question is not whether an AI can act in a staged demo, but whether it can help under real operating conditions and remain dependable when an incident is unusual.
Key Questions
What does “AI SRE” mean?
In the report, it is a broad label for AI-assisted on-call and incident-response tools that help gather evidence, investigate alerts and sometimes triage pages. It does not describe the full scope of site reliability engineering.
Can AI SRE agents fix production incidents on their own?
The report says fully autonomous agents of the kind shown in conference demonstrations are not current reality. Whether an agent should make and deploy code changes remains debated because an incorrect fix could worsen an outage.
Why are companies paying more attention to these tools?
The report links the interest to more frequent software changes and cites Rootly data showing pages have risen year over year, with outside-business-hours pages nearly doubling. The figures are attributed to Rootly and do not establish that AI coding tools caused the change.
How can teams tell whether an AI SRE system works?
The report says accuracy is difficult to assess and varies by organization. Teams can test agents against past incidents and compare their diagnoses and response times with existing processes, but the source does not identify a shared industry benchmark.
Source: newsletter.pragmaticengineer.com
