MTTR vs MTTD: What is the Difference?

What is MTTD?

MTTD is an acronym for “mean time to detect,” which refers to the average amount of time that passes between when a failure happens and when the system realizes it. MTTD is a key metric when analyzing how your team can relate IT changes to incidents. The faster you detect anomalies, the faster you can solve problems.  

To understand why MTTD and MTTR start with the word “mean,” we have to take a quick trip back in time to middle school math class. 

You calculate the mean of a set of numbers by adding them all together and then dividing by how many numbers were in the data set, just like an average. When it comes to MTTD, you get the mean by adding together all the different times that passed between when a failure happened and when it was detected, then dividing it by the number of instances. 

An MTTD data set can be relatively simple. It could look like this: 

• Monday: Your web server goes down at 2:00 p.m. The system discovers and reports the failure at 2:05 p.m. Discovery time is five minutes. 
• Wednesday: The same web server goes down at 11:00 a.m., and the failure is discovered at 11:15. Discovery time is 15 minutes. 
• Thursday: The server fails again at 1:00 p.m., and this is discovered at 1:04. Discovery time? Four minutes. 

5 + 15 + 4 = 24, so your MTTD would be that total, divided by the number of incidents in the data set, or three. That gives you an MTTD of eight minutes.  

However, MTTD can also hinge on someone speaking up and others listening. For example, suppose your e-commerce solution is failing due to an error in a database containing customer information. When a customer complains to a rep in your company, you could‌ say the MTTD clock has started. How stakeholders respond will make all the difference in a lower MTTD and, ultimately, customer satisfaction.

What is MTTR?

MTTR is a slightly more flexible acronym signifying “mean time to recover,” but the last “R” can also stand for “repair,” “restore,” “resolve,” or “remediate.” MTTR is the average time that passes between when a failure has been discovered and when it has been fixed. 

Depending on the systems in place, MTTR can vary a lot more than MTTD. With automated visibility solutions, MTTD can often be a function of programs that detect faults. MTTR, on the other hand, often involves people and a series of steps needed to fix the issue. So while MTTD may be a measurement of how well an automated alert system performs, MTTR often ends up being a measurement of both your systems and the people you depend on to jump into action after an incident.

Cut recovery time with SUSE Cloud Observability

SUSE Cloud Observability helps organizations consolidate their monitoring systems data, visualize their entire Kubernetes environment in a single topology view, enhance IT observability and identify root cause faster than ever before. With real-time observability, the time it takes to discover a failure is cut down because admins and other stakeholders can see alerts from all segments of the stack and immediately pinpoint the root cause. This results in better MTTD numbers and greater resiliency. 

The same is true for SUSE Cloud Observability’s impact on MTTR. A true recovery can’t happen unless you first identify the root cause. Otherwise, you may be slapping a Band-Aid on a cut that’s deeper than you realize. Because SUSE Cloud Observability has a complete understanding of the IT environment, its relationships, dependencies and the changes taking place within it, when a problem arises, the system can immediately pinpoint what has changed and the associated problems. No more hunting for the cause, no more “blame games” of “guilty until proven innocent” and fewer war rooms. This is supported by curated dashboards of core Kubernetes metrics that allow you to monitor performance and detect issues quickly.

Learn how to reduce MTTR for Kubernetes issues in our e-book: The how-to guide for troubleshooting Kubernetes apps with better observability.