What is MTTM?

#How MTTM is measured

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.

#Why MTTM matters

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.

#Limits and risks

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.

#MTTM vs 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.

#Key takeaways

• MTTM measures time to reduce user impact, whether or not the underlying cause has been addressed.
• Terminology and endpoint definitions vary across organizations and tools; publish the exact local definition alongside the metric.
• Rollback, failover, feature flags, and load shedding are the standard mitigation levers.
• Mitigating first converts an emergency into a normal engineering problem, producing better permanent fixes.
• Mitigations without follow through accumulate into a system held together by workarounds.

#Frequently asked

Should teams optimize for mitigation over diagnosis?

Yes, during an incident. Stop the user impact first, then diagnose without pressure. The reverse order extends impact while people investigate.

What makes a good mitigation lever?

Fast, reversible, and independent of knowing the cause. Rollback and traffic shifting qualify because they work regardless of what broke.

When is mitigation not possible?

When impact is already realized, as with data corruption, or when the failing component has no alternative path. Those incidents require an actual fix.