The Economics of Operational Excellence

The morning after the 2:14 a.m. payments incident, the report to the CIO had one line: payments service degraded, resolved after 94 minutes.

Three engineers paged, four tools searched and a lesson learned for the second time didn't appear anywhere. Neither did the cost. Nobody sends an invoice for an engineer's night. It sits in payroll, spread across salaries, and that's why one of the largest operating costs in IT almost never shows up as its own budget line.

This is the last post in the series on Agentic IT Operational Excellence. The earlier posts covered where incident time goes, why investigation is slow, how agents work on a unified layer, the controls they need and how to scale them across teams. This one puts numbers on it, and leaves the parts only you can fill in blank.

Incident time is a payroll line nobody budgets

Start with how much time goes to incidents. In February 2026 NeuBird surveyed 1,039 SRE, DevOps and IT operations professionals. Most said their teams spend 40% or more of their time managing incidents instead of building systems, and the share was consistent from engineers up to leadership (vendor-run survey). Catchpoint's SRE Report shows the same direction, with median toil rising from 20% to 34% in a single year (vendor-run survey). Google's original SRE guidance caps operational work at 50%, so engineers always keep at least half their time for engineering. Many organizations are now close to that line.

Turn that share into money. Take a team of ten SREs with 40% of their time on incidents:

• At international cost levels, about $150,000 per engineer a year, that's roughly $600,000 a year of payroll spent on incidents.
• At Vietnamese cost levels, about $40,000 per engineer a year, it's roughly $160,000 a year.

Not all of it can be recovered. New failures still need people, and they should. A business case should rest on your own incident classification (how many incidents are repeats of known failures, how many are noise, how many are new) instead of on someone else's benchmark.

Most of the value is uptime, not headcount

When people build the case for agents in operations, they usually start with engineer time. It's the easiest number to find. It's also the smaller one.

Here's an illustrative model for that same ten-person team. The assumptions are deliberately conservative: engineers spend 40% of their time on incidents and agents recover only 20% of that. There are 12 customer-facing incidents a year, and half of them get cut from 99 minutes to 14, the illustrative timeline from the hidden cost of incident time. A minute of degraded service costs $1,000 at international levels and $200 at Vietnamese levels.

01Payroll in incidents

~$600,000 a year

Ten SREs at $150,000 each, with 40% of their time spent on incidents.

02Engineer time recovered

$120,000

A conservative 20% of that incident time given back to engineering work.

03Uptime protected

$510,000

Six customer-facing incidents a year cut from 99 to 14 minutes, at $1,000 a minute.

Most of the value comes from uptime. Cutting the degraded time of recurring incidents from about 99 minutes to about 14 protects revenue and SLA commitments, and that's worth several times the engineer cost recovered. Uptime is about four fifths of the total in the international column and three quarters in the Vietnam column. Even where engineers cost less, it's the larger line.

That changes who should care. A case built on engineer time is an operations efficiency story, and it invites the question "so how many people can we cut?" A case built on uptime is a revenue protection story, and it belongs in front of the business.

Build the value model with your own numbers

The table above is a shape, not a forecast. Replace every assumption with your own data. The model has four lines.

01Incident payroll

Engineers × cost × share

Headcount, fully loaded cost and the share of time that goes to incidents.

02Recoverable time

× what agents can take

Only the part spent on known, recurring failures. New failures still need people.

03Uptime

Minutes saved × cost per minute

Customer-facing incidents per year, minutes saved on each, cost of a degraded minute.

04Cost side

Your volume × your quote

Your investigation volume times the price you are quoted, plus rollout effort.

1. Incident payroll. Your headcount in operations, their fully loaded cost and the share of their time that goes to incidents. If you don't know the share, measure it for a month. Most ITSM systems only record when an incident opens and closes, so you may need to ask engineers directly.
2. Recoverable time. The part of that payroll spent on known, recurring failures, noisy alerts and risky changes that could have been caught before release. Start low. 20% is a conservative place to begin.
3. Uptime. Your customer-facing incidents per year, the minutes an agent would realistically save on each, and what a degraded minute costs you in revenue and SLA penalties. Your finance team usually has a number for that last one, even if nobody in engineering has asked for it.
4. Cost side. Your expected investigation volume times the price you're quoted, plus the effort of rolling out. I'm leaving this line blank on purpose. Count the alerts that get ignored today too: once every alert gets investigated, your volume will be higher than your current incident count.

Then compare value with cost, using numbers you trust because they're yours.

You don't have to take the assumptions on faith. Run agents read-only for the first 30 days, alongside your team, on your own incident data. Compare their verdicts with your postmortems and their timelines with your real MTTI. By day 30 you'll know how close your recoverable share is to the 20% assumption. The 90-day rollout in the controls post covers what comes after that.

The weekly team scorecard

A business case gets the programme approved. A scorecard keeps it honest.

Excellence needs a scoreboard: every team, measured every week, on the same five problems that years of transformation left behind.

01Cost

Cloud spend

Change in spend for the services the team owns.

02Reliability

MTTR

How long the team takes to recover service.

03Security

Open risks

Known weaknesses still waiting for a fix.

04Velocity

Change failure rate

The share of changes that cause a failure.

05People

Toil per week

Hours spent on repetitive, manual operations work.

Here's what that looks like with five teams. The numbers are illustrative.

The value of a table like this is in the trend column. Who's improving fastest. Whose score is slipping. It turns operational excellence into a shared goal instead of a blame game, and it puts the five problems on one page where engineering and the business both read them.

Each column has an agent working on it. Optimize works on cost, Resolve on time to recover, Cyber on open risks and Review on change failures. Teams that measure something specific to how they work build their own with Customize, and track it on their own scorecard.

Under the scorecard, keep the monthly operating metrics from why incident investigation is slow: the share of time on incidents, the repeat rate, investigation time (MTTI), the share of alerts that lead to action, the completion rate of prevention items, and time to remember. Time to remember explains the others. When it falls, repeats fall, MTTI falls and the share of time on incidents falls with them.

Five questions for your next leadership meeting

The value model gives you numbers. These five questions tell you whether you're ready to use them. I'd bring them to the next leadership meeting before any budget conversation.

1. How much of our engineers' week goes to investigating rather than building?
2. How long does it take us to understand an issue, as well as fix it?
3. How much of our cloud spend could we explain to the board today?
4. If our two most experienced engineers left tomorrow, what would we lose?
5. Where could agents help today, with a person approving every step?

The first two are the incident payroll and MTTI lines of the value model. The third is the cost column of the scorecard. The fourth is company memory, which no budget line shows. The fifth is where the pilot starts.

If I were starting today

The series overview gives the short version: start small, take a baseline, test agents read-only on last week's issues and grow one team at a time. Here's what I'd add once money is involved. Make the baseline the five scorecard measures, with investigation time split out from the total.

Two decisions I'd make before the first access is granted. Set the thresholds for scaling up front (the MTTI improvement, the repeat rate and the minimum return that move you from pilot to wide rollout), because a bar decided afterwards always moves. And decide where the recovered time goes, because time nobody assigns gets absorbed. I'd put it on the prevention items that keep slipping behind the roadmap, since those are what stop the next repeat. When agents start proposing changes, they go through Auto Mode, so the team decides what runs on its own and what waits for approval. The controls post covers the rest, and from single agents to a shared platform covers the second team.

What the money is really for

In the agentic era, I think the biggest value of operational excellence is an organization that remembers what it learned and spends its engineers' time on problems nobody has solved yet. Cutting operations headcount is the smaller prize.

No system eliminates incidents. The realistic goal is fewer repeats, so every new incident gets full attention and is remembered for good. The Frontier Investigation Agents do the investigation. People make the calls.

Engineers get their time back. For creative work. And the organization gets a little smarter with every incident.

Related reading

• Agentic IT Operational Excellence: the series
• The hidden cost of incident time
• Why root cause analysis takes hours
• Frontier Investigation Agents
• CloudThinker Resolve
• CloudThinker Optimize

Sources

• NeuBird AI, 2026 State of Production Reliability and AI Adoption Report, survey of 1,039 professionals, February 2026 (vendor-run survey).
• Catchpoint, The SRE Report 2026 (vendor-run survey).
• Google, Site Reliability Engineering, chapter 5, "Eliminating Toil". sre.google