MTTR vs MTTF: Why AI Teams Need a Better Reliability Metric<br>Engineering<br>July 23, 2026·13 min read<br>MTTR is the Wrong Metric for AI-Era Engineering Teams
AI tools produce 41% more bugs and 98% more pull requests. MTTR can't keep up. Here's how MTTF shifts your team from incident response to prevention.
Evan MarshallCTO
Key takeaways<br>MTTR assumes failures will happen and measures how fast you respond. As AI accelerates code output and bug rates rise 41% with it, optimizing recovery time means accepting that your customers will regularly pay the price.
MTTF reframes the goal: measure how long it has been since a customer had a bad experience, not how fast you cleaned up after the last one. Prevention compounds; recovery resets you to day zero.
Closing the gap requires fixing the code review bottleneck before deployment. Static analysis catches some issues; runtime analysis catches the behavioral bugs that only surface when code actually runs. Together, they make MTTF achievable.
AI makes code generation and deployment faster, but our safeguards haven’t caught up.<br>For over a decade, mean time to recovery, or MTTR, was the industry’s primary protective measure against bad code. Organizations assumed failure was inevitable and used MTTR to measure how fast they could recover. The smaller your MTTR, the better.<br>MTTR, however, doesn’t map to AI-era failure modes. It doesn’t meaningfully capture the speed of AI-generated code production, nor the potential blast radius of autonomous agents.<br>Every engineering team is already rethinking their deployment process, so it’s time to rethink recovery, too.<br>Enter mean time to failure, or MTTF.<br>MTTF first emerged in hardware contexts, where it referred to the average operating time before a non-repairable component broke and required replacement. In software, we can use the same framework to focus on the component we can’t have broken: Your customer’s experience.<br>DORA, SRE, and the assumption of failure<br>MTTR might feel like it’s been around forever, but it’s only been around for about a decade. It has its roots in DORA and site reliability engineering (SRE), both of which were responses to the rise of distributed computing.<br>MTTR was a valid response to a real shift in how we produce software, but with the rise of AI, old ideas working from previously valid principles can cause damage. That’s why it’s worth rewinding to see why MTTR emerged, and why it no longer suits what we need today.<br>DORA: DevOps Research & Assistance<br>The first study in what would become DORA attempted to tie IT performance to organizational performance. The goal was ambitious: How could organizations link sometimes abstract-feeling technical goals to real business value?<br>The research turned up four values, split into two categories:<br>1 Throughput measures: Deployment frequency and deployment lead time.<br>2 Stability measures: MTTR and change fail rate.<br>Note that, in the years since, there have been updates. In 2023, DORA renamed MTTR to failed deployment recovery time to focus on failures caused by software changes, rather than events like data outages. And in 2024, DORA added a fifth metric: deployment rework rate. By then, however, MTTR had already become the de facto term.<br>In the years since, DORA has become the preeminent methodology for measuring performance, replacing (and in many cases upgrading) other methods. These five metrics subsequently became canonized, and even organizations that don’t use DORA know to prize these metrics.<br>(Source)<br>As DORA metrics were taking off, Google was formalizing a new role and philosophy: Site Reliability Engineering, or SRE. The SRE approach emphasizes automation, reliability, and hands-on incident management. This places SRE engineers in charge of building fault-tolerant systems and minimizing failure.<br>MTTR became a key metric for Google’s SREs, resulting in MTTR’s spread as other organizations adopted SRE roles.<br>As the metric spread, business leaders keyed in, too. Many organizations defaulted to these metrics, along with the frameworks they implied, to build consensus across teams. Over time, organizations could capture failure in one simple number, and trust everyone understood what they meant. Shared understandings can be dangerous, however, when new concepts unseat previously foundational assumptions.<br>The limitations of MTTR<br>MTTR is a widely accepted standard. The problem with standards is that the map can be mistaken for the territory. What happens then when the territory changes underneath this map?<br>Goodhart’s Law and its consequences<br>When Anthropic published a case study with Spotify, the online response wasn’t entirely positive, with developers pointing out that velocity doesn’t equal value, and fewer bugs don’t mean a better experience.<br>As Mitchell Hashimoto, cofounder of HashiCorp, writes in a representative post, “This is the problem with a lot of AI reporting. It reports completely meaningless metrics.”<br>Production deploys per day, proportion of...