Availability, Not Uptime: Why Time-to-Repair Is Half Your Retention Equation (2026)

Answer first: availability is a ratio - time working divided by time working plus time broken - and product teams fund only the numerator. Halving how often something breaks and halving how long it stays broken move the ratio by exactly the same amount, but the second is usually cheaper, faster, and entirely unbudgeted. And the clock your customer is running started long before the ticket you are measuring, which is why your mean time to repair is not the number you think it is.

Reliability engineers have a formula that product teams have never borrowed. Inherent availability is

A = MTBF / (MTBF + MTTR)

where MTBF is mean time between failures and MTTR is mean time to repair. It has two terms. A component that fails every 1,000 hours and takes 10 hours to fix has the same availability as one that fails every 100 hours and takes 1 hour to fix. Both are 99.0 percent. One of them is described in every engineering roadmap as "more reliable." Neither is.

Now translate it. For a customer relationship, MTBF is how often something goes wrong for them - a bug, a failed import, a billing surprise, a promised feature that slipped. MTTR is how long they live with it before it is genuinely resolved. Almost every retention initiative on almost every roadmap attacks the first term. Almost nothing attacks the second, because the second is owned by support, measured in a different system, reported to a different executive, and never appears in a product review.

The half of the equation nobody funds

The prevention bias is not irrational. It is just incomplete. Prevention is legible: you can name the bug you fixed. Recovery speed is diffuse: no single person can point at the two days you removed from a queue.

But the arithmetic is unforgiving, and it gets more unforgiving the more reliable you already are.

The two right-hand columns are not close. They are exactly equal, in every row, always - and that is algebra, not coincidence. Doubling MTBF gives 2M / (2M + R). Halving MTTR gives M / (M + R/2), which is the same fraction with the numerator and denominator both doubled. The two levers are the same lever.

The only thing that distinguishes them is cost, and reducing time-to-resolution is almost always the cheaper of the two, because it does not require you to find and fix an unknown defect - it requires you to shorten a queue you can already see.

Google's Site Reliability Engineering team frames the same trade-off from the other end, and their conclusion is worth quoting because it cuts against the instinct of every product leader: "we strive to make a service reliable enough, but no more reliable than it needs to be." They go further: "a user on a 99 percent reliable smartphone cannot tell the difference between 99.99 percent and 99.999 percent service reliability." Past a threshold, buying another nine on the failure side is invisible to the customer. Time-to-repair never becomes invisible, because the customer is awake for all of it.

Your MTTR measures the middle of the clock

Here is the part that makes the metric worse than merely incomplete. Your systems start the repair clock when a ticket is created and stop it when a ticket is closed. The customer's clock starts when the thing stopped working for them and stops when they trust it again. Those are not the same interval, and the difference is not a rounding error.

Three of the five segments are invisible, and two of them come before you have any record at all. This is why a support dashboard showing a four-hour median first response can coexist with customers who describe the same problem as having consumed their week.

There is now a hard number on the customer-side version of the clock. The 2025 National Customer Rage Study - the eleventh wave of a survey run by Customer Care Measurement and Consulting with Arizona State University's W. P. Carey School of Business, fielded among 1,000 Americans and originally designed to replicate a 1976 White House study - reports that 77 percent of customers experienced a product or service problem in the past year, a rate that has more than doubled since 1976. Among those with a problem, 59 percent said it wasted their time, by an average of one full day, and 45 percent reported a financial loss averaging $1,008. Sixty-four percent reported feeling rage about it.

One full day. Compare that to whatever number is on your support dashboard this morning. The gap between the two is the part of MTTR you have never measured, and it is where the relationship is actually damaged.

The reporting latency problem, which is the expensive one

Of the invisible segments, reporting latency is the one that should worry you most, because for a large share of problems it never ends. The customer notices, decides it is not worth the effort, works around it, and files nothing. Your MTTR for that problem is undefined, and your failure count is short by one.

The same study offers a lens on how that decision gets made. Complainant satisfaction has, after remaining stagnant for more than forty years, risen across the last three waves - and it now sits at 40 percent of complainants reporting they were delighted or completely satisfied with how their issue was resolved. That is a historic high. It is also a statement that three out of five people who took the trouble to complain did not get a resolution they were happy with. When a customer weighs whether to report the next problem, that is the base rate they are working from.

And when they do reach out in public, the study found 43 percent said the company never responded. Silence is not a neutral outcome in an availability calculation. It sets the repair clock running indefinitely.

The honest limit: do not conclude that breaking things is fine

There is a well-known finding in services research called the service recovery paradox - the claim that a customer whose problem is recovered exceptionally well ends up more loyal than one who never had a problem at all. It is quoted constantly, usually to justify spending on recovery theatre.

The evidence does not support the strong version. de Matos, Henrique and Vargas Rossi's meta-analysis in the Journal of Service Research (10(1):60-77, 2007) pooled the studies testing it and found the paradox is significant and positive for satisfaction, but nonsignificant for repurchase intentions, word of mouth, and corporate image. Excellent recovery makes people feel better about the episode. It does not, on the pooled evidence, make them buy again more than customers who were never let down.

So the argument of this article is precisely not "let it break and recover brilliantly." It is narrower and more defensible: at whatever failure rate you actually have, the time-to-repair term is doing half the work on availability and receiving a small fraction of the investment. Fix the failures you can. Then go and find the days.

Where the days are, and why only research finds them

Detection latency, reporting latency and trust recovery are not in your logs by construction. They are facts about what a person noticed, concluded and decided. There is exactly one instrument that measures them, and it is a conversation.

Four questions that recover the invisible segments, phrased so they do not lead:

1. "When did you first notice something was wrong?" - not "when did you report it." The gap between those two answers is your reporting latency, and it is usually the largest single segment.
2. "What did you do before you contacted us?" - surfaces the workaround, which is the thing that made the problem tolerable and therefore invisible to you.
3. "Was there a point where you decided not to report something?" - this is the question that finds the failures missing from your failure count entirely.
4. "When did you start relying on it again?" - trust recovery. Frequently weeks after the ticket closed, and occasionally never; some accounts keep the workaround forever, which quietly caps the value they get from you.

Ask these of the same problem across twenty accounts and you can reconstruct the full clock: real detection-to-resolution duration, the share of problems never reported, and the trust tail. That is a customer-truth MTTR, and it is the only version of the number that belongs in an availability calculation.

How Koji helps

The reason nobody runs this study is timing and volume. The answers degrade fast - reporting latency is a memory of a decision, and it blurs within days - so the interview has to happen close to the incident, not in a quarterly research cycle. Manual moderation cannot meet that timing at any meaningful volume.

Koji closes the gap:

• AI-moderated interviews triggered by an event - a ticket resolution, an incident close, a support escalation - so the conversation happens while the timeline is still recoverable, not six weeks later when everyone has rounded it to "it took ages."
• Structured questions turn a duration into typed data. Koji supports six types - open_ended, scale, single_choice, multiple_choice, ranking, and yes_no - and a clock-reconstruction study is a single_choice on when they first noticed, a yes_no on whether they ever considered not reporting it, a scale for confidence at the point the ticket closed, a ranking of which delay segment hurt most, a multiple_choice on the workarounds they used, and an open_ended probe where the AI follows whatever the answers imply.
• Automatic thematic analysis groups the reasons people did not report, which is the single highest-value output of the whole exercise and the one that never survives manual coding because the sample is spread across hundreds of small incidents.
• Voice interviews work far better than typing for reconstructing a sequence of events, because people narrate timelines naturally and type them badly.
• Real-time reporting lets you watch the reconstructed MTTR move after a process change, rather than waiting a quarter to learn whether the change did anything.

Against legacy tooling the contrast is structural, not incremental. A post-resolution CSAT survey in a traditional survey tool asks whether the customer was satisfied - one number, collected after the clock stopped, with no mechanism to reconstruct the segments before the ticket existed. It cannot ask a follow-up. And a single_choice question about a problem someone chose not to report cannot be asked at all by a tool that only fires on closed tickets. AI-moderated interviews reach the accounts with no ticket, which is exactly where the missing time lives.

How to put this next to a prevention project

Recovery work and prevention work compete for the same budget, and they are usually presented in incompatible units - "reduces P1 incidents by 30 percent" against "cuts median resolution by a day." Neither can be compared to the other, and neither can be compared to its cost.

Convert both into a count. Number needed to treat - how many customers you must reach to produce one retained account - puts a prevention project and a queue-shortening project into the same currency, and it is the only form in which the cheaper option becomes visible. Do the conversion before the prioritisation meeting, not during it.

One caution on the baseline that feeds that calculation: if the retention number you are improving was computed by treating every kind of exit as the same event, it is inflated, and the competing-risks correction has to happen first. An overstated baseline makes every intervention look cheaper per save than it is - prevention and recovery alike.

A working checklist

1. Write down your availability as a ratio, per customer segment, using durations rather than incident counts. If you cannot, you have been managing only the numerator.
2. Instrument the two clocks separately: the system clock (ticket open to close) and the customer clock (noticed to trusted again).
3. Interview 15 to 25 accounts after real incidents and reconstruct all five segments. Do it within a week of resolution.
4. Estimate your never-reported rate. Any answer other than zero means your failure count is wrong too.
5. Compare the cost of removing one day from the queue against the cost of preventing one incident class. Run the arithmetic before assuming prevention wins.
6. Set a target on time-to-trust, not time-to-close. Closing a ticket is your event; relying on the product again is theirs.
7. Do not use the service recovery paradox as a justification for anything. Recovery restores sentiment, not, on the pooled evidence, repurchase behaviour.

Frequently asked questions

What is mean time to repair in a customer context?

It is the average duration a customer spends with something broken, from the moment it stops working for them to the moment they trust it again. That is deliberately wider than the support-desk definition of ticket-open to ticket-close, because the customer's clock includes the time before they reported it and the time after you closed it during which they still worked around it.

Why does availability depend on repair time as much as failure rate?

Because availability is MTBF / (MTBF + MTTR), and both terms sit in the denominator. Doubling the time between failures gives 2M / (2M + R); halving the time to repair gives M / (M + R/2), which is the identical fraction. The two changes produce exactly the same availability, always. The difference between them is cost, not effect, and shortening a visible queue is usually cheaper than finding an unknown defect.

How much of my repair clock is invisible?

Three of the five segments - detection latency, reporting latency, and trust recovery - leave no trace in your systems. The 2025 National Customer Rage Study found 59 percent of customers with a problem said it wasted their time by an average of one full day, which is an order of magnitude larger than most support dashboards show for the same class of problem.

Is the service recovery paradox real?

Partly. The meta-analysis by de Matos, Henrique and Vargas Rossi (Journal of Service Research, 2007) found a significant positive effect of excellent recovery on satisfaction, but nonsignificant effects on repurchase intentions, word of mouth, and corporate image. Treat it as evidence that good recovery repairs how an episode feels, not as a licence to under-invest in prevention.

What questions reveal the parts of the clock I cannot log?

Ask when they first noticed rather than when they reported; what they did before contacting you; whether there was a point they decided not to report something; and when they started relying on the feature again. The first and third questions recover the two segments that precede any record you hold.

Should I set an SLA on time-to-trust?

Set a measurement on it first. Time-to-trust is recovered from interviews rather than logged, so it moves on a research cadence rather than a real-time one, and turning an interview-derived number into a contractual commitment before you understand its variance is a mistake. Measure it quarterly, target it internally, and keep the contractual SLA on the segments you can actually observe.

Related Resources

• The Churn Hazard Curve: Why One Churn Rate Hides Three Different Problems - where in tenure the failures you are pricing actually concentrate
• Structured Questions in AI Interviews - the six question types, and how to turn a reconstructed timeline into typed data
• Support Ticket Analysis: How to Mine Customer Service Data for Product Insights - what the visible middle of the clock can and cannot tell you
• Customer Retention Research: The Complete Playbook - the prevention-side programme this article is the counterweight to
• Crisis Customer Research - how to research during the incident rather than after it
• IT Service Management Survey Guide - the internal-facing version, where the same two clocks apply to employees