Toil Is Rising Again: SRE Time Economics in 2026

Key Takeaways

• Google's target is that at least half an SRE's time goes to engineering, not toil. The SRE Book states: "At least 50% of each SRE's time should be spent on engineering project work that will either reduce future toil or add service features."
• Reported toil rose sharply year over year. The 2026 Catchpoint SRE Report found that "median reported toil increased again, rising to 34% compared with 20% the previous year."
• Most practitioners credit AI with reducing toil anyway. The same report: "49% say AI has decreased toil." Both things are true at once, which is the puzzle.
• Confidence in overseeing AI is low. "Only 13% describe themselves as very or extremely confident in their ability to monitor AI reliability."
• The view of AI's toil impact splits by seniority. A companion Catchpoint analysis reports "60% of directors said AI reduced toil, compared to 38% of individual contributors."
• Toil is defined precisely, which is why it can be measured. Google: toil is "the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value."
• AI can shift toil rather than remove it. New oversight work, verifying and monitoring AI, is itself manual and repetitive, and it lands on the people least confident they can do it.

Toil, the manual and repetitive operational work Google says should consume less than half an SRE's time, is rising again: a 2026 survey of reliability practitioners puts median reported toil at 34%, up from 20% the prior year, even as nearly half of respondents say AI reduced their toil. Those two findings sit in the same report and do not contradict each other. Reconciling them is the useful part.

This post defines toil precisely, lays out the 2026 numbers, and explains why AI can lower the toil people notice while raising the toil they measure.

What counts as toil, and how much is too much?

Toil has a specific definition, which is what makes it measurable rather than a mood. Google's SRE Book describes it as "the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value." The test is not whether work is unpleasant; it is whether it scales linearly with service size and leaves nothing behind.

The threshold is equally specific: "At least 50% of each SRE's time should be spent on engineering project work that will either reduce future toil or add service features." The reason for a hard cap is that "toil tends to expand if left unchecked and can quickly fill 100% of everyone's time." Toil is not a fixed cost. Left alone, it grows to consume the capacity that would have reduced it.

How much toil are SREs actually reporting in 2026?

More than the year before. The 2026 Catchpoint SRE Report found that "median reported toil increased again, rising to 34% compared with 20% the previous year." The word "again" matters: this is a trend, not a one-year blip.

At 34% median, the reported figure still sits under Google's 50% ceiling, so the headline is not that teams have breached the limit on average. It is the direction and the pace. A jump from 20% to 34% in a single survey cycle, during a period of heavy AI adoption in operations, is the finding worth explaining.

Reference point	Value	Source
Google's engineering-time floor	At least 50% of time on engineering	SRE Book
Median reported toil, prior year	20%	Catchpoint 2026
Median reported toil, 2026	34%	Catchpoint 2026
Say AI decreased their toil	49%	Catchpoint 2026
Very or extremely confident monitoring AI reliability	13%	Catchpoint 2026

If AI reduces toil, why is measured toil going up?

Both statements are in the same report: "49% say AI has decreased toil," and median toil "rising to 34% compared with 20%." The resolution is that AI removes some toil while creating a different kind.

The likeliest mechanism is substitution, not elimination. AI drafts a runbook step, summarizes a log, or proposes a fix, which removes visible, tedious work. But it adds new work that fits the definition of toil just as well: reading and verifying AI output, catching the "almost right" answer, and monitoring whether the AI is behaving. That oversight work is manual, repetitive, and tactical. It is toil by Google's own definition, and it did not exist before.

The confidence data supports this reading. "Only 13% describe themselves as very or extremely confident in their ability to monitor AI reliability." When the people responsible for oversight are mostly not confident they can do it well, the oversight burden is heavy and unresolved, which is precisely what shows up as rising measured toil. The measurement problem behind that low confidence is covered in can you measure an AI SRE's accuracy.

Why do managers and engineers disagree about it?

Because they do different work. A companion Catchpoint analysis reports that "60% of directors said AI reduced toil, compared to 38% of individual contributors." That is a 22-point gap on the same question.

The gap is explained by who touches the AI's output. Directors see aggregate throughput and fewer visible complaints; individual contributors do the line-by-line verification of AI-drafted work and absorb the new oversight toil directly. When leadership concludes AI is working and the people doing the checking disagree, the disagreement is not noise. It is a signal about where the new toil landed, and it tends to land on the least senior people.

What actually reduces toil without just relocating it?

The goal is elimination, not substitution. A few principles hold up against the 2026 data.

1. Automate the class, not the instance. Google's cap exists because toil regrows. Automating one runbook helps once; encoding an invariant so a whole failure class self-heals helps permanently. The distinction is the difference between doing toil faster and removing it.
2. Count oversight as toil and budget for it. If AI adds verification work, that work belongs in the toil measurement. A tool that produces confident output you cannot inspect raises oversight toil even when it looks like it is saving time.
3. Make AI output inspectable, so verification is fast. The oversight burden is proportional to how hard the output is to check. Reasoning that states what it ruled out and flags its own confidence is faster to verify than a bare verdict, which is why Aurora rejects sub-agent findings that lack a "What I ruled out" section and a self-assessed strength.
4. Keep humans in the loop for action, not for reassurance. Human-gating a production change is worthwhile toil. Re-reading an AI summary because you do not trust it is toil with no enduring value; fix the trust problem instead.
5. Prefer deterministic remediation for well-understood failures. If a failure class is fully understood, a state machine beats a model, and it generates no oversight toil at all. See automated incident remediation and automated alert noise reduction.

The through-line: AI is worth adopting in operations, but it only reduces net toil if the oversight it creates is smaller than the toil it removes, and that is a measurement, not an assumption.

Where does an AI investigation tool fit this picture?

Honestly, it can go either way, and the deciding factor is inspectability. An investigation assistant that compresses the mechanical parts of incident work, reading unfamiliar logs, correlating a deploy with an onset time, checking whether a commit actually shipped, removes real toil, because that work scales badly for humans under pressure. But if its output is a confident black box, it adds oversight toil that can exceed what it saved.

Aurora is built for the inspectable case rather than the black-box case. Its investigation prompts distinguish symptom from cause in the open-source repository, sub-agent findings are rejected unless they state what was ruled out and a self-assessed confidence, and a structural chokepoint denies mutating writes when no interactive human is present. Those are design choices aimed at keeping verification cheap, not a claim that any tool reduces toil on its own. The only way to know is to measure oversight toil on your own team, which is why the install below matters more than any survey number. For the surrounding practice, see the SRE incident lifecycle with AI agents and root cause analysis for SREs.

Measure it on your own team

Aurora is Apache 2.0 and self-hostable, so you can test whether it removes more toil than it adds on your own incidents rather than trusting a survey average. One LLM API key is the only hard requirement; cloud connectors are optional.

git clone https://github.com/arvo-ai/aurora.git && cd aurora

make init                # generates secrets, copies .env.example to .env
nano .env                # add OPENROUTER_API_KEY (or OPENAI_API_KEY / ANTHROPIC_API_KEY)
make prod-prebuilt       # pulls prebuilt images from GHCR and starts

Open http://localhost:3000. The first user to register becomes admin.

Run it through a few real investigations and track two things: the mechanical work it removed, and the verification work it added. If the second is larger than the first, it is relocating toil, not reducing it, and you will know rather than assume.

• Start free: aurora-ai.net (hosted, no infrastructure to run)
• GitHub: github.com/Arvo-AI/aurora
• Related guides: Can You Measure an AI SRE's Accuracy? · The SRE Incident Lifecycle With AI Agents · Automated Incident Remediation · Root Cause Analysis for SREs

Sourcing note. The 50% engineering-time floor, the definition of toil, and the observation that toil expands to fill available time come from Google's SRE Book chapter on eliminating toil. The 34%-versus-20% median toil figure, the 49% who say AI decreased toil, and the 13% confident in monitoring AI reliability come from the 2026 Catchpoint SRE Report blog. The director-versus-individual-contributor split (60% versus 38%) comes from Catchpoint's companion analysis of the same report. Figures behind Catchpoint's gated PDF are not used here. Verified 24 August 2026.