It depends on the service and your targets. Compare it with your error budget: a 99.9% monthly target allows 43 minutes of downtime, so with two incidents a month each one has to be fixed in about 20 minutes.

What is the difference between MTTR and MTTA?

MTTA runs from the alert until someone acknowledges it. MTTR covers the whole incident, from the start of the outage until the service works again, so MTTA is part of MTTR.

How do I calculate MTBF?

Divide the total time the service ran without incidents by the number of incidents in the period. For example, 43,100 minutes of uptime with 4 incidents gives an MTBF of 10,775 minutes.

How does monitoring improve MTTR?

It cuts detection time. With one-minute checks and confirmed alerts sent to the right channel, the team learns about an outage within a minute or two instead of from a customer.

MTTR, MTTA and MTBF Explained with Examples

MTTR (mean time to recovery, or repair) is the average time from the start of an incident until the service works again. MTTA (mean time to acknowledge) is the average time from an alert until someone confirms they are working on it. MTBF (mean time between failures) is the average time a service runs normally between incidents. Together they describe reliability: MTBF says how often things break, MTTA how fast you respond and MTTR how long customers are affected.

This guide covers the definitions, the formulas, a worked example with numbers, which timestamps to collect and the practical changes that improve each metric.

The metrics and what they measure

MTTR: four meanings, one acronym

MTTR is the most quoted incident metric and the most confusing, because the R stands for different things depending on who uses it:

Mean time to repair: from the start of the repair work until the fix is in place. Common in hardware and maintenance.
Mean time to recovery (or restore): from the start of the outage until the service works again for users. The most useful version for websites and APIs.
Mean time to respond: from the alert until the team starts acting. Close to MTTA.
Mean time to resolve: until the incident is fully closed, including the follow-up that stops it from happening again.

None of them is wrong. What matters is that you pick one, write the definition down and use it consistently. Comparing your “recovery” number with someone else’s “repair” number tells you nothing. In this article, MTTR means mean time to recovery: from when the service broke until it worked again.

MTTD and MTTA: the response before the repair

MTTD (mean time to detect) is the time from the start of an incident until monitoring raises an alert. MTTA is the time from that alert until a person acknowledges it. Both sit inside MTTR, which is why they matter so much: no one can fix a problem they have not heard about.

MTBF: how often things break

MTBF is the average uptime between incidents. A higher number is better. Its cousin MTTF (mean time to failure) is used for things that are replaced rather than repaired, such as disks; for online services, MTBF is the one you need.

The formulas

MTTD = total time from incident start to alert / number of incidents
MTTA = total time from alert to acknowledgement / number of incidents
MTTR = total time from incident start to recovery / number of incidents
MTBF = total operating time without incidents / number of incidents

Availability = MTBF / (MTBF + MTTR)

The last line shows why both sides matter. You can improve availability by having fewer incidents (higher MTBF) or by shortening them (lower MTTR). Shortening them is often far cheaper.

A worked example

Here is an example month for an online shop, with four incidents. The numbers are made up for illustration, but the timestamps are the kind any monitoring tool gives you.

Incident	Started	Alert	Acknowledged	Recovered	Detect	Acknowledge	Recover
Checkout 503	03:12	03:13	03:16	03:19	1 min	3 min	7 min
API timeouts	10:05	10:06	10:08	10:41	1 min	2 min	36 min
Login errors	14:30	14:31	14:45	15:02	1 min	14 min	32 min
Search down	22:50	22:51	22:56	23:15	1 min	5 min	25 min

Now apply the formulas:

MTTD = (1 + 1 + 1 + 1) / 4 = 1 minute.
MTTA = (3 + 2 + 14 + 5) / 4 = 6 minutes.
MTTR = (7 + 36 + 32 + 25) / 4 = 25 minutes.
MTBF: a 30-day month has 43,200 minutes. Minus 100 minutes of downtime leaves 43,100. Divided by 4 incidents, MTBF is 10,775 minutes, about 7.5 days.
Availability = 10,775 / (10,775 + 25) = 99.77%.

Two things stand out. The 14-minute acknowledgement on the login incident pulls MTTA up from about 3 minutes to 6, so it is worth asking why nobody picked up that alert. And at 99.77%, this shop is well short of a 99.9% target, which allows only 43 minutes a month. If you are setting such targets, read SLA vs SLO vs SLI for how they fit together.

Now imagine the same month with five-minute checks and no confirmation step. Detection could take up to five minutes instead of one, adding as much as four minutes to every incident. MTTR rises from 25 to as much as 29 minutes before anyone has done anything differently.

Which timestamps to collect

You need four timestamps per incident. Most of them come straight from monitoring:

Start: the first failed check. External monitoring records it even when your servers log nothing.
Alert: when the failure was confirmed and the notification went out.
Acknowledged: when a person said “I’m on it”. If you have no on-call tool, a reply in the incident channel works; note the time.
Recovered: the first passing check after the incident, which is also when the recovery notice goes out.

With Uptimecheck, the start, alert and recovery times and the total downtime are part of every incident, and weekly and monthly reports summarise uptime and incidents. Exports to CSV or JSON make it easy to calculate the averages in a spreadsheet. Record the acknowledgement time in your incident notes or postmortem.

A practical warning: averages hide outliers. One six-hour incident and nine one-minute blips average out to about 37 minutes, which describes neither. Look at the median and the longest incident alongside the mean, and review the slowest incidents one by one.

How to reduce detection time

Check every minute

The check interval is the upper limit of your detection time. One-minute checks on everything that earns money or serves customers is the single cheapest improvement to MTTR. Use 1-minute uptime monitoring for every critical page and endpoint.

Check what breaks, not just what loads

Incidents that monitoring does not see are detected by customers, often hours later. Validate the content of important pages, monitor the API endpoints apps rely on, and add heartbeats to scheduled jobs. Every incident that a customer reports first is a gap in your monitoring.

How to reduce acknowledgement time

Send confirmed alerts only

Slow acknowledgement is usually a trust problem. If half the alerts are false, people learn to wait and see. Confirm failures from a second location before alerting, and remove monitors that alert without anyone needing to act. Our guide to reducing false alerts covers the details.

Route alerts to the right channel

An email at 03:12 will be read at 07:30. Send critical monitors to a channel that reaches the on-call person’s phone and to a team chat for everyone else, and keep less urgent monitors on email. Uptimecheck lets you choose alert channels per monitor: email, Slack, Discord, Telegram, Microsoft Teams and webhooks, on every plan.

Make ownership clear

An alert sent to five people is often acknowledged by none. Name one owner per service and one on-call person per shift. Everyone else gets the information, not the responsibility.

How to reduce repair time

Write runbooks for known failures

Most incidents repeat. The disk fills up, a worker pool is exhausted, a certificate renewal fails. A short runbook per monitor turns a half-asleep investigation into a checklist:

Runbook: checkout returns 503
1. Check the server dashboard: CPU, memory, disk on web-01 and web-02.
2. Check PHP-FPM status: sudo systemctl status php8.3-fpm
3. If workers are exhausted: sudo systemctl restart php8.3-fpm
4. Check for long-running jobs: ps aux --sort=-%cpu | head
5. Still failing after 10 minutes? Escalate to the lead developer.

Keep the runbook link where the alert lands, for example pinned in the incident channel, so it is one tap away.

Put cause and symptom side by side

When a website check fails, the first question is usually whether the server is out of memory, CPU or disk. Having server metrics next to uptime checks shortens that step from an SSH session to a glance.

Keep rollback easy

Many incidents start with a deploy. If rolling back is one command, recovery takes minutes. If it needs a meeting, it takes an hour.

Update the status page early

A status page does not shorten the outage itself, but it shortens the part customers feel worst: not knowing. It also keeps support from being flooded while the team is fixing the problem. A status page connected to your monitors shows the affected component as soon as the incident opens; add a short note on what you are doing and when you will update next.

Improving MTBF

Fewer incidents come from learning from the ones you had. After each significant incident, write a blameless postmortem, agree on one or two action items and track them until they are done. Over a few months, the same failures stop coming back and MTBF rises.

Start measuring with real timestamps. Try Uptimecheck free for 14 days, no credit card required.

MTTR, MTTA and MTBF Explained (and How to Improve Them)