TLDR overview
- “MTTR” means different things for production incidents, code findings, and CI failures. Define the start and end events for each before you compare anything.
- AI may shorten parts of the path: triage, log summarization, context gathering, fix drafting. Whether it shortens the whole path is a hypothesis to test, because review queues, failed attempts, and rework can absorb the gains.
- Compare equivalent work with and without AI, ideally in a controlled pilot, and pair MTTR with unresolved-item age, reopen rate, failed-fix rate, and review effort.
- Start with one bounded workflow, a documented baseline, explicit permissions, written verification criteria, and a review checkpoint.
A model can draft a patch in the time it takes to read the error message. That change is real, and it is easy to see. What is harder to see is whether the problem was resolved any sooner: whether the patch was right, whether anyone reviewed it, whether CI went green and stayed green, and whether the same issue came back next week.
That gap matters to anyone trying to connect AI investment to an operational outcome. Counts of generated code and accepted suggestions measure activity. Anecdotes about time saved are persuasive and hard to check. Mean time to resolve (MTTR) is attractive because it measures an outcome the business cares about, but only if you measure the whole path to a verified result.
It is also timely for teams that use SonarQube. SonarQube Server’s project dashboards, available starting in the Enterprise edition, now include Mean time to resolve widgets for code issues. That gives code remediation a documented clock to measure against.
Faster suggestions do not necessarily mean faster resolution. Measure the complete path to a verified outcome, including review, failed attempts, and rework.
The rest of this article treats “AI lowers MTTR” as a hypothesis to test, not a claim to repeat. It covers where AI may help, where the gains tend to leak away, how to run a fair comparison, and how to start a pilot small enough to learn from.
What does “AI in MTTR” actually mean?
Start with the acronym. Atlassian’s incident management guide notes that the R in MTTR can stand for repair, recovery, respond, or resolve, and advises teams to agree on which one they mean. Its definition of mean time to resolve is a broad one: it covers detecting, diagnosing, and repairing a failure, plus the time spent making sure it does not happen again. DORA’s delivery metrics have moved from “MTTR” to “failed deployment recovery time,” defined as the time it takes to recover from a deployment that fails and requires immediate intervention.
So “AI in MTTR” needs a qualifier. At least three different workflows are measured under the same name, and each has its own clock.
SonarQube documents its MTTR for code issues as the average time between an issue being detected and resolved. That is the code-finding clock. It is not the incident clock and not the CI clock, and the three should not be averaged together or reported as one number. A pooled “AI cut MTTR” headline would hide more than it shows.
One boundary matters for the rest of this article. SonarQube and Gitar work on code and CI. Neither is a production incident-response tool, and nothing here claims they reduce production recovery time. Treat incident response as its own workflow with its own measurement.
Where AI may shorten the resolution process
Between detection and a verified outcome, there are several steps where AI could remove work. The table lists the usual candidates and the catch with each. Treat every row as a proposed benefit. A tool’s documentation tells you what it can do. It does not tell you what it did for your team, on your code, at your review capacity.
Some of these steps are documented for specific tools. For CI failures, Gitar’s documentation describes reading CI logs, identifying the failing step and root cause, and then suggesting or applying a fix, and it describes deduplicating identical failures across jobs. Documented capability is not demonstrated effect, and results vary with context. DORA’s 2025 research describes AI’s primary role as an amplifier, magnifying an organization’s existing strengths and weaknesses, which is one reason another team’s pilot is weak evidence for yours. Vendor demos, ours included, show that a workflow can work. They do not show how often it works on your code.
Why faster fixes don’t always mean lower MTTR
A generated patch is not a verified resolution. The clock should stop at a verified outcome, and several things can happen between the patch and that point.
Wrong diagnosis. If the root cause is misread, a fast fix lands in the wrong place, and the cost includes the time it takes to notice. A fluent explanation can make a wrong hypothesis harder to question.
Unsafe or incomplete changes. A patch can silence a symptom, handle one case and break another, or satisfy the checks that happened to run. Passing CI means the configured checks passed. It does not prove the software is free of defects, and Gitar’s own documentation separates the two: passing CI and covering the requested behavior, it says, answer different questions.
Review queues. A patch that arrives in seconds still waits for a person. If AI increases the number of patches, queues can grow, and each patch can take longer to review. In Sonar’s State of Code Developer Survey of more than 1,100 developers, 38% said reviewing AI-generated code takes more effort than reviewing code written by colleagues. That is self-reported perception, not measured review time, but it points to where work may move.
Repeated CI failures. Each failed attempt costs a full pipeline cycle, and a fix can introduce a new failure. Gitar documents this: CI failures may not be resolved in a single pass, so it supports multi-iteration fixing, and its automatic recovery path stops after three consecutive Gitar commits. Three attempts through the same pipeline cost three pipeline cycles, not one.
Rework and recurrence. A resolved item that reopens, or a fix that causes a regression, was not resolved. MTTR can also fall for the wrong reason. If items are dismissed, or re-run until they pass, rather than fixed, the clock stops sooner and the risk remains.
A simple test: does the change reduce, shift, or add work?
For each stage of the workflow, label what AI did to the work, using measured time rather than impressions.
Only the net effect on the end-to-end clock matters. A tool can reduce work in one stage, shift it in another, and add some in a third, and still leave MTTR where it started. If the stage AI speeds up is a small share of elapsed time, even a large speedup there barely moves the total. In some workflows much of the elapsed time may be waiting rather than working, so check your own timestamps before assuming otherwise.
How to measure AI’s effect on MTTR
The most reliable approach is a controlled pilot: equivalent work, with and without AI assistance, measured with the same clock. When that is not feasible, a careful before-and-after comparison can show an association, but on its own it cannot show that AI caused the change.
Be careful with language. A randomized comparison supports a statement such as “AI assistance reduced median CI-to-green time in this pilot.” A before-and-after comparison supports “median CI-to-green time fell after we introduced AI assistance,” and if anything else changed in that window, that is as far as it goes. “No detectable difference” is also a legitimate result.
Expect measurement to be hard. METR studied open-source development tasks, not MTTR, but its experience is instructive. In a 2025 randomized trial that assigned tasks to “AI allowed” or “AI disallowed,” developers’ own estimates of AI’s effect did not match the timing data. In February 2026, METR reported that a follow-up gave an unreliable signal, in part because developers declined to work without AI and chose which tasks to submit, and because time was hard to record when several agents ran at once. The lessons carry over: take timestamps from systems rather than memory, and guard against people steering items into one condition.
Allow for the learning curve, and for low volume. DORA’s ROI report on AI-assisted development speaks to teams managing the initial “productivity dip” of a new rollout, so a pilot that ends too early may measure onboarding rather than steady state. For production incidents, Google SRE’s report on incident metrics argues that statistics such as MTTR are poorly suited to decision making or trend analysis. Incidents are often few in number, which is one practical reason to start a first pilot on a higher-volume workflow.
Pair MTTR with quality and risk measures
MTTR counts only what got resolved, and it is an average. Both properties can mislead. A team can lower MTTR by closing easy items quickly while hard ones age. A handful of long-running items can swamp a mean, and a mean can look flat while the typical item improves. DORA lists “one metric to rule them all” among the common pitfalls and recommends several metrics, including some with a healthy amount of tension between them. It also warns against setting metrics as goals, citing Goodhart’s law.
Use medians and tail measures such as the 90th percentile alongside the mean where your data supports them. Resolution times are often skewed, with many quick items and a few very slow ones. With small samples, percentile estimates are noisy, so show intervals or the raw distribution. SonarQube’s MTTR widgets are documented as averages. If you need medians or tails, check what your data export or API provides and compute them from the underlying items.
These companion measures are where an AI tool’s quality effect shows up. If MTTR falls while the failed-fix rate, reopen rate, or review effort rises, the work has moved somewhere your headline number does not look.
A practical example: code remediation and CI failures
To make this concrete, here is one flow from failure or finding to verified outcome, built from two separately documented capabilities. Gitar documents CI failure analysis, configurable fix application, and iterative repair. SonarQube separately documents MTTR for code issues in its project dashboards. They are separate products with separate documentation, and nothing below assumes they feed one report.
A retry is not a fix. Gitar can automatically retry CI jobs whose failures it classifies as unrelated to the pull request, such as flaky tests or transient infrastructure problems, at most once per commit and only when that setting is enabled, on supported CI platforms. A build that goes green on a retry reached green without a code change. Record those cases separately, or CI-to-green can improve without anything having been resolved.
Green is not the same as verified. In a walkthrough Sonar published in June 2026, a pull request reached green CI and Gitar’s approval, and SonarQube’s quality gate still blocked it on issues the AI review had not flagged. It was a constructed demo on a purpose-built repository, so it says nothing about how often this happens. It does show why verification criteria should be written down in advance, and why more than one layer should check the result.
Keep the reporting boundary clear. The same guide, which covers SonarQube Cloud, describes the two products as independent layers that report separately on a pull request, with no shared dashboard or quality gate. This article does not describe a combined MTTR view across Gitar and SonarQube, and you should not assume one exists. If you want one, build it from your CI and Git host timestamps and SonarQube’s data, and state which clock each number comes from. A Gitar fix commit re-triggers your pipeline, and any SonarQube analysis step in it, like any other commit, but that is pipeline behavior, not combined reporting.
Start with a measurable, bounded pilot
You do not need an organization-wide program to learn whether AI shortens resolution on your code. You need one workflow, a clear clock, and the discipline to count the whole path.
- Pick one workflow. CI-to-green on a defined set of repositories, or code-finding resolution for one severity band or rule category. Do not mix workflows. Keep production incidents out of the first pilot unless you have the volume to measure them.
- Document the baseline. Capture current MTTR with its median and tail, the age of open items, and the resolution mix over a representative period. Write down the start and end events, and log any rule, pipeline, or staffing changes that happen during the pilot.
- Set explicit permissions. Decide whether the AI may only suggest or may also apply changes, in which repositories and branches, and who approves. For Gitar, the documented controls include an auto-apply toggle, scope settings for authors and target branches, a label to skip a pull request, and separate approval and merge options. Keep auto-approve and auto-merge off during the pilot, and remove secrets before pasting log excerpts into comments. Check availability against your plan, code host, and CI platform before you start.
- Write the verification criteria. For example: required checks pass, a reviewer approves, a later analysis confirms the finding is gone, and the item does not reopen or cause a regression within a set number of days. Apply the same criteria to AI-assisted and unassisted work.
- Schedule a review checkpoint. Look at the distribution, failed-fix rate, reopen rate, and review effort at a midpoint and at the end. Decide in advance what would make you pause, such as an unsafe change reaching a protected branch.
- Report what you found, including null results. State the sample size, the confounders, and whether the comparison was randomized.
AI may shorten the path, lengthen it, or move work from one place to another. A bounded pilot is the cheapest way to find out which, and a verified outcome is the only stopping point that counts.
Next steps
Measure code remediation. See how SonarQube Server project dashboards report Mean time to resolve for issues. Project dashboards are available starting in the Enterprise edition.
Evaluate CI failure remediation. Read Gitar’s CI failure analysis documentation, check its plans and platform support against your setup, and trial it on a bounded set of repositories using the pilot structure above.