What is MTTM?

The clock runs from detection to the point where user impact is materially reduced, whether or not the cause has been addressed. Rolling back a bad deploy, failing over to a healthy region, disabling a broken feature flag, and shedding load are all mitigations.

The distinguishing property is that the users stop being affected while the underlying defect remains. That defect is then fixed under normal conditions rather than under incident pressure, which produces better fixes.

Mitigation is what users actually experience as the incident ending, and it is almost always achievable faster than a real fix.

• Impact duration: the number that most closely tracks how long users suffered.
• Pressure relief: once mitigated, the team can diagnose carefully instead of frantically.
• Better fixes: permanent solutions written calmly are better than those written at 3am.
• Realistic target: teams can be fast at mitigation even when root causes are hard.

Mitigation without follow through accumulates hidden risk. A team that reliably fails over and never addresses why the primary failed builds a system held together by mitigations, and eventually a failure arrives that the mitigation does not cover.

Some incidents also have no mitigation available. Data corruption, certain state inconsistencies, and failures in a single-point of dependency have to be genuinely fixed, and for those MTTM converges on MTTR.

MTTR is measured to restoration, and depending on the organization's definition that may mean service restored or cause eliminated. MTTM is explicitly the first of those.

Separating them clarifies the strategy. A team optimizing MTTM builds fast reversible levers: rollbacks, feature flags, traffic shifting, load shedding. A team optimizing MTTR alone tends to focus on diagnosis speed. Mature incident response prioritizes mitigation first and diagnosis second, because a mitigated incident is no longer an emergency.