Lightstep from ServiceNow Logo





Lightstep from ServiceNow Logo
< all blogs

MTTA, MTTR, MTBF, MTTF: A Guide to Understanding Incident Metrics

For today’s businesses, technical incidents come with significant consequences. Companies can suffer major losses due to lost productivity, lost revenue, and maintenance costs when a system goes down.

According to a recent Uptime Institute survey, sixty-two percent of significant outages cost more than $100,000 USDsixty-two percent of significant outages cost more than $100,000 USD, with fifteen percent of these outages costing over $1,000,000 dollars. Effectively tracking incident management metrics is more important than ever to the success of your business.

MTxx or Mean Time to XX metrics are used to measure the average time it takes for a team to detect, diagnose, remedy, and prevent incidents. The “X” can represent a stage or event in the incident management process.

MTTA, MTTR, MTBF, and MTTF are four commonly used metrics for incident management that help organizations identify and diagnose problems in their systems, create more efficient incident management systems, and reduce the number of incidents to better serve customers.

A diagram showing how MTxx incident metrics help teams measure the average time to diagnose and remedy incidents. “X” can represent a stage in the incident management process

In this guide, we’ll explain these metrics, their definitions, how to calculate them, and how you can use them to improve your incident management systems.

What Is MTTA?

Mean time to acknowledge or MTTA is a key performance indicator in incident management. It measures the average time between when an incident alert is created, to when the team acknowledges the issue.

In incident management, MTTA is used to measure a team’s responsiveness to incidents over a specific time period; it also helps track the effectiveness of your alert systems and your customer complaints. It can be measured by team, service, severity, and incident owner.

Tracking and reducing MTTA allows companies to optimize their processes, while increasing customer satisfaction and boosting profits.

A diagram showing Mean Time to Acknowledge (MTTA) - the average time between when an incident occurs and the team acknowledges the incident and begins repairs

How to Calculate MTTA

MTTA  is the raw time between When an alert notification has been sent to a user (usually the on-call user for the team that owns what's affected), and when that user manually acknowledges that they are working that issue. It is calculated by totaling the time between alert and acknowledgment for a specific time period, then dividing that total by the total number of incidents within the same time period.

MTTA = sum of all time to acknowledge periods / total number of incidents

Example MTTA Calculation

A system goes down in three separate incidents over sixty days. The first time, it takes your team twenty minutes to acknowledge the outage, the second time, it takes ten minutes, and the third, fifteen minutes.

So, your MTTA can be calculated by dividing the sum of all the incidents by the number of incidents:

Sum of all time to acknowledge periods = 20 + 10 + 15 = 45 minutes

Total number of incidents = 3

MTTA over 60 days = 45 / 3 = 15 minutes

The Importance and Usefulness of MTTA

MTTA is important for organizations because it shows how responsive the site reliability engineering (SRE) and other support teams are to incidents as they develop. Slow response times can cause reduced employee productivity, lost revenue, and dissatisfied customers.

A low MTTA means you’re acknowledging, prioritizing, and responding to the incidents that affect important business processes in a timely manner. This translates to less downtime, fewer business disruptions, and happier end users.

A higher MTTA means your team is taking too long to acknowledge and respond to incidents or that responders are not responsive or available when they receive a alert. This could be due to alert fatiguealert fatigue—when teams become overwhelmed by too many alerts, and either ignore them or fail to prioritize them. To solve for this, escalation policies are usually put into place to offer a set of additional resources to notify for acknowledgement, if the first resources does not do so within a particular timeframe.

In this digital age, customers expect a rapid response to their issues. Failing to respond quickly to incidents can result in almost immediate customer dissatisfaction. Monitoring MTTA provides insight into how to make long-term improvements to team responsiveness and streamline incident management efforts.

Minimizing MTTA allows your SRE teams to optimize their processes, improve customer satisfaction, and enhance profits; it also lets you know if your efforts to reduce time to acknowledgment are successful.

What Is MTTR?

MTTR can actually refer to several different metrics that are useful in different circumstances, but covering all of these is beyond the scope of this article.

This article focuses on the mean time to repair (MTTR) metric, which measures the average time between the start of an incident and when the system, application, or piece of infrastructure returns to acceptable service levels in production. It’s a measurement of how quickly a devops team responds to and repairs unplanned outages.

MTTR begins when repairs start, and takes into account the time needed to alert technicians, and analyze, diagnose, and repair time spent on the problem, so that the system, application, or hardware is fully operational again. However, it doesn’t consider the time taken to order and receive parts.

The MTTR metric is not always equal to the same time period for the entire system outage, as there might be a lag between when the issue occurs, when it’s detected, and when the team begins repairs.

A diagram showing Mean Time to Repair (MTTR) - the average time between when repair starts on an incident and when the system resumes operations

How to Calculate MTTR

To calculate MTTR, first, select a period of measurement, eg, weekly, monthly, quarterly, or yearly, then divide the total time your team spent on repairs during that period by the total number of repairs performed.

MTTR = time spent on repairs / total number of repairs for the selected period

Example MTTR Calculation

In the first quarter of the year, your team spends a total of thirty hours repairing your operating system in response to faults caused by six incidents.

Time spent on repairs = 30 hours

Total number of repairs = 6

MTTR for that quarter = 30 hours / 6 repairs

MTTR = 5 hours

The Importance and Usefulness of MTTR

MTTR is a significant indicator of how an incident will affect an organization and is most useful for tracking how quickly your organization can respond to and repair failures. Using MTTR, organizations identify and remove inefficiencies that lead to lost productivity and revenue.

An initial MTTR will help you understand how much you need to improve to develop a more successful MTTR for your business. It can be used by support and maintenance teams to increase response times and the efficiency of repair processes. MTTR and your service level agreements (SLAs) can also provide insight into how effectively you’re providing the promised support services.

A good MTTR depends on several elements, including the type of technology, its age, and how critical it is to your business. You should aim to keep MTTR low. A low MTTR shows that a component or service can be repaired quickly, and its failure will have a minimal impact on the business. A good way to reduce MTTR is by consolidating your context for your systems (service dependencies, change history, metrics, logs, traces) so that you can quickly diagnose and remediate the issue.

A higher MTTR suggests a greater risk that when an IT incident occurs, the organization will experience a significant disruption of service, leading to customer dissatisfaction, SLA violation, and loss of revenue.

Understanding MTTR can help you improve incident response processes, make repair or replace decisions for aging technology products, predict lifecycle costs for new systems, and better understand how to schedule repairs.

What Is MTBF?

Mean Time Between Failures or MTBF is the average time between repairable failures for a technology product (eg, systems, applications, or hardware infrastructure). It’s a critical metric for measuring the frequency of failures for repairable products.

Besides measuring reliability, MTBF can also be used with MTTR (mean time to repair), another failure metric, to calculate the availability of the product.

Availability = MTBF/(MTBF+MTTR)

MTBF only focuses on unexpected failures and downtime, and doesn’t include scheduled outages and downtime that result from planned or reactive maintenance.

maintenance. Noisy systems that alert too frequently due to failure are prime candidates to deprecate or update to reduce team toil.

MTBF is not a fixed value; it will decrease as the technology’s failure rate increases towards the end of its useful lifetime.

A diagram showing Mean Time Before Failure (MTBF) - the average time between failures for a device or system that can be repaired

How to Calculate MTBF

MTBF is calculated by dividing the total operational time for a repairable system or device by the number of failures observed over a specific time period. Calculations can be based on multiple failures related to a single technology product, or failures related to multiple technology products of the same type.

Mean Time Between Failures = total hours of operational time / total number of failures

Total operational time is the total time a technology product has been operational without incident over the time you want to analyze (eg, four months, two years).

The number of product failures is the total number of failures for these products over the same time period. Data is taken over a period with multiple failures to calculate an arithmetic average or mean.

Example MTBF Calculation

Your operating system experiences four random crashes over the course of thirty days (720 hours), and the total amount of downtime resulting from these incidents was forty-eight hours.

Total number of failures = 4

Total hours of operational time = 720 - 48 = 672

MTBF = 672 / 4 = 168 hours

Calculating MTBF from Failure Rate

MTBF is the inverse of the failure rate and can therefore be calculated from a known failure rate.

Failure rate = the number of incidents divided by total operational time

MTBF = 1 / Failure Rate

Example MTBF Calculation from Failure Rate

Failure rate = 20 failures divided by 1,000 hours of uptime

Failure rate = 0.02

MTBF = 1 / 0.02

MTBF = 50

The Importance and Usefulness of MTBF

In SRE practices, MTBF typically measures the availability and reliability of IT environments, as opposed to the performance of the DevOps or SRE teams managing the environment.

As such, MTBF is most useful for helping you predict and prevent unplanned outages. Measuring MTBF gives you important information about a failure and helps you mitigate its impact. MTBF analysis will help determine how successful teams are at preventing and reducing incidents in the long term, so you can reduce downtime and increase productivity.

You can use MTBF to optimize your maintenance schedule, evaluate maintenance processes, improve inventory management, and make better CapEx decisions. An initial MTBF gives a baseline for preventative maintenance.

An approximate timeline for when a system, application or piece of infrastructure will fail can help you better gauge when you need to schedule preventive maintenance.

MTBF also provides better insight into what components you need to order and keep on hand for more efficient inventory management. Increasing your MTBF also makes it easier to decide to replace a technology product rather than repair it, so you can ensure better use of human and financial resources.

Companies aim to keep MTBF as high as possible. A low MTBF puts the reliability and availability of your system into question. You may need to conduct root cause analysis to gain more insight into incidents and implement preventative maintenance measures. Conversely, the more time there is between incidents, the more reliable the system is. Fewer incidents mean less downtime and reduced costs.


MTBF and MTTR are distinct steps in the same process. MTBF measures the reliability of a piece of technology and lets the team know how often the organization’s systems and infrastructure are likely to break down. A higher MTBF indicates the technology product will take longer to fail.

MTTR measures the efficiency of repairs and shows how fast the team can get things up and running again. An organization should aim to increase MTBF and reduce MTTR to minimize or avoid unplanned downtime.

What is MTTF?

MTTF or mean time to failure is an incident management metric that measures the average operational time for non-repairable technology products such as systems, applications, or infrastructure, before they fail completely. MTTF only records one failure per product and is only used for products that cannot or should not be repaired, such as a light bulb.

MTTF can help you understand how long a product will last on average, determine the product’s expected lifetime, and be a basis for scheduling preventative maintenance. The more technology products you observe, the more accurate your MTTF metric will be.

MTTF can also be used with SLAs to inform customers about expected system lifetimes and when to schedule system maintenance.

A diagram showing Mean Time to Failure (MTTF) - the average time it takes for an unrepairable system or device to fail completely

How to Calculate MTTF

To calculate MTTF, you need to:

  1. Determine the number of technology products you want to assess.

  2. Determine the combined total hours of operation for all the products.

  3. Divide the total hours of operation time for the products you’re assessing by the total number of products.

MTTF = total hours of operation across devices / total number of failed products

Example MTTF Calculation

As MTFF is more suitable for products that fail once, the previous example of an operating system is not as suitable for this metric. So, the following example uses MTTF to determine how long a particular brand of hard drive lasts on average before it fails.

In this example, you’ve decided you want to assess four hard drives of the same brand. Hard Drive 1 lasts five hundred thousand hours, Hard Drive 2 lasts four hundred thousand hours, Hard Drive 3 lasts seven hundred thousand hours, and Hard Drive 4 lasts eight hundred thousand hours.

Total hours of operation = 2,400,000 hours

Total number of failed products = 4

MTTF = 2,400,000 hours / 4 hard drives

MTTF = 600,000 hours for this brand of hard drive

The Importance and Usefulness of MTTF

System or application failure can have a detrimental impact on service delivery, revenue, and customer satisfaction. MTTF can improve preventative maintenance processes. If a system and its components are always in good working order, the system is perceived as more reliable.

There are several situations where MTTF can help you improve your maintenance strategy. MTTF can be valuable for non-repairable systems, applications or infrastructure where preventative maintenance will prolong the life of the product.

If you know that a certain part or component has an average lifespan of twenty thousand hours, you can more accurately estimate when to order a replacement and have it arrive before the entire system breaks down.

MTTF can also help you reduce costs when deciding what parts and equipment to purchase. Regularly scheduled maintenance reduces the number of parts you need to buy, and you can budget more efficiently if you know approximately when you need to buy components.

A good MTTF will be relative to the specific piece of technology and your business objectives. Typically, the longer the MTTF, the better. When determining a good MTTF for your organization, consider the technology’s expected lifetime, its operating environment, and how it compares to similar technology products in similar environments and use cases.

The MTTF metric can also be used to evaluate suppliers. An increasingly shorter MTTF on devices or components from the same supplier could be a red flag regarding quality. This might indicate that you need to change suppliers or at least have a conversation with your current supplier about the quality of their product.


So what’s the difference between MTTF and MTBF? Well, MTTF is used for systems, applications or infrastructure that cannot be repaired and must be replaced when they fail, in other words, failure occurs only once. MTBF is used for technology products that can be repaired when they fail, in other words, failure can occur multiple times.

MTTF allows you to average the lifetime of similar technology and is a good measurement of the entire lifetime of a system or component. MTBF, on the other hand, measures how much time you have before a technology product fails again and tells you how successful your team is at preventing and reducing future issues.


In this guide, you’ve learned how to use the MTTA, MTTR, MTBF, and MTTF incident metrics to evaluate the effectiveness of your incident management systems and processes. When used together, they give a holistic view of how successful your team is at managing incidents and where they can improve.

Software tools such as Lightstep’s all-in-one incident response platformLightstep’s all-in-one incident response platform can give your team the data it needs to better understand incident management metrics.

With Lightstep, it’s easy for DevOps and SRE teams to monitor and respond to changes in the IT environment, and so minimize the impact of system incidents. You can reduce metrics such as MTTA and MTTR with integrated collaboration, and counter alert fatigue with customized alert notifications and automated resolutions.

Lightstep also integrates with the most popular applications for devops, collaboration, monitoring and sending alerts and your other existing tools, so you can automatically gather information across all your systems.

Sign up for a free trial of Lightstep Incident ResponseSign up for a free trial of Lightstep Incident Response

July 11, 2022
14 min read

Share this article

About the author

Deborah Ruck

Deborah Ruck

Read moreRead more

Monitoring PostgreSQL with OpenTelemetry and Lightstep

Robin Whitmore | Feb 15, 2023

Get an in-depth walkthrough of how to set up monitoring of your PostgreSQL instance with OpenTelemetry and Lightstep.

Learn moreLearn more

Three Terraform Mistakes, and How to Avoid Them

Adriana Villela | Nov 16, 2022

Learn how to fix three Terraform gotchas around module and provider configurations.

Learn moreLearn more

Defining Services for Incident Response

Darius Koohmarey | Oct 17, 2022

In Lightstep Incident Response, we believe in defining the service on every alert or incident. There are numerous benefits associated with this approach.

Learn moreLearn more

Lightstep sounds like a lovely idea

Monitoring and observability for the world’s most reliable systems