SRE Toil Has Risen Two Years Running While AI Spread

SRE toil is the repetitive, manual operational work that grows with a service instead of producing lasting value. We care about the number because it decides how much of an engineer's week remains for work that reduces future incidents, and because AI tools are being bought largely on a promise to cut it.

The recent survey data does not clearly show that promise being kept. It also does not show why, so most explanations in circulation, including some of ours, are hypotheses.

In this post we cover what the last three SRE reports say about toil, why survey data cannot settle the cause, three hypotheses with a test for each, four questions to ask before pointing AI at operations, when rising toil is not an AI problem and how to measure the effect on your own team.

What the Last Three SRE Reports Say About Toil

Google's SRE book chapter on toil defines it as work that tends to be "manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows", and sets "an advertised goal of keeping operational work (i.e., toil) below 50% of each SRE's time."

Catchpoint's annual SRE Report measures how far teams are from that goal. The 2025 edition, based on 301 respondents surveyed in July and August 2024, said "After five years of steady decline, the median reported percentage of work spent on toil has increased to 30% from 25% in 2024." It added that "The expectation was that AI would reduce toil, not exacerbate it."

The 2026 edition, based on 418 responses collected in July and August 2025, reported "Median toil is 34% of engineers' time. While 49% report AI has reduced toil, others report no change or increased burden."

Put together, the medians run from 25% to 30% to 34%. That is a clear direction, though not a clean experiment, and we explain why next.

Survey Data Shows an Association, Not a Mechanism

Three limits stop us from reading the trend as proof that AI adds toil. Each report surveys a different group of respondents, 301 in one and 418 in the other, so a change in the median may partly reflect who answered.

Toil is also self-reported, which means a team that begins to recognise work as toil can report more of it without doing more of it. The Google definition is narrow, and it excludes overhead such as meetings and work with long-term value, so respondents may apply it unevenly.

Finally, the surveys report adoption and toil side by side, not a change in toil within one team after one tool. We can say that toil rose during a period of AI adoption, and that about half of respondents credit AI with reducing it. We cannot say which tools help or hurt.

That leaves the question of mechanism open, and a fair answer is a set of hypotheses that a team can test on itself.

Three Hypotheses for Rising SRE Toil and How to Test Each

These are our working explanations, not findings from the surveys. For each one we state the signal it predicts, a test any team can run, and what result would count against it.

Hypothesis	Predicted signal	Test	Evidence against it
Verification burden	Engineers spend time checking AI output	Time the check on a sample of AI answers against the time to do the task unaided	Checks take far less time than the original task
New operational surface	Pages and tickets about the AI tooling itself	Count incidents, upgrades and on-call work attributable to AI systems	AI systems generate almost no operational work
Automation aimed at the wrong loop	Speed gains in steps that were never the bottleneck	Compare where incident time goes before and after the tool	The tool shortens the longest step

1. Verification Burden Offsets the Speed of Generation

An AI system can draft a summary or a fix in seconds, yet an experienced engineer still has to decide if it is right. If checking takes as long as doing the task, the work has changed form and the hours are the same.

The test is simple and uncomfortable. Take twenty recent AI outputs, time the person who verified each one, and compare with how long the underlying task takes without the tool. We would also record how often the output was wrong, because a wrong answer that is believed costs far more than one that is caught.

The hypothesis predicts that the saving shrinks as the stakes rise. Low-risk summaries are cheap to check, while a proposed root cause for a production incident may need the whole investigation repeated, and that is where an independent check on the evidence earns its place. Our guide to verifying AI root cause analysis describes one way to make the check cheaper.

2. AI Systems Are a New Operational Surface

AI features are software, and software needs deploying, monitoring, patching and paging. Model gateways, retrieval indexes and agent runtimes add components that fail in their own ways, and someone carries the pager for them.

If this hypothesis holds, toil attributable to the AI stack should be visible in tickets and incidents. Tag a quarter of operational work by whether it concerns AI tooling, and compare with the time the tooling is said to save.

The failure modes here are often quiet. A pipeline can return plausible answers while degrading, which we covered in our look at silent failures in AI agent pipelines, and detecting that is itself operational work.

3. Automation Aimed at the Wrong Loop

The third hypothesis is about targeting. If AI is applied to steps that were already quick, such as routing or paging, while the long steps remain manual, aggregate toil need not fall.

We would break a sample of recent incidents into phases and find where the hours went. For some teams the longest phase is diagnosis, and we argued in how to reduce MTTR by attacking the diagnosis bottleneck that the first investment belongs there when it is.

Against this hypothesis would be a finding that the tool shortens the longest phase. In that case the toil trend probably has another cause, and the next section lists some.

Four Questions to Ask Before Pointing AI at Operations

Whatever the cause, a few questions separate tools that remove work from tools that move it. We ask them before any rollout, and we apply them to our own tooling as well.

• Does it produce evidence or actions? Gathering logs, diffs and traces for a human to judge removes legwork without adding blast radius.
• Who verifies the result, and is checking cheaper than doing? A tool whose output needs an hour of review for a ten minute task has not saved anything.
• Does it remember earlier incidents, or does every spike start from zero? Repetitive work needs repeated patterns to be recognised.
• Is it governed, with an audit trail and read-only access by default? Unsupervised changes create exactly the supervision burden the tool was meant to remove.

An AI agent that investigates with evidence is built around the first two questions, since it gathers evidence from connected systems and shows its work for an engineer to review.

When Rising Toil Is Not an AI Problem

Toil can rise for reasons unrelated to AI. Services multiply, traffic grows, and an alert rule written for a smaller system fires ten times a day on a larger one. Capacity and unplanned work compete for the same hours, as we showed in our capacity math for unplanned work.

Survey composition matters too. If a later edition draws more respondents from large organisations or from operations-heavy roles, the median may move without any change in practice. And teams that adopt a measuring discipline often report higher toil at first, because they finally count it.

We would therefore avoid concluding that AI is responsible before checking the simpler explanations in your own data. If toil is rising and AI was introduced at the same time, the tests above separate the two, and a null result on all three hypotheses is a useful answer.

Measure SRE Toil Before and After Every AI Rollout

We would pick one definition, ideally Google's, and apply it to the same team in the same way before and after. Record hours of toil, hours spent verifying AI output and hours spent operating the AI tooling, so each hypothesis has a number attached.

Review the numbers with the engineers who do the checking, because they know which outputs were trusted and which were redone. The survey medians tell us the direction of the industry, and only your own measurements tell you what a given tool did for your team.

If SRE toil has not fallen after a quarter, that is evidence about the tool or its target, not about the engineers. Operate runs dedicated AI agents inside your own infrastructure that investigate production issues through read-only adapters, and every finding cites its evidence.