⏱️ Reducing MTTR: Where the Time Actually Goes and How to Cut It

Everyone wants to lower MTTR, and almost everyone optimizes the wrong part of it. Teams pour effort into faster deploys and slicker rollback tooling — the fix — when the data from real incidents shows the fix is rarely where the time goes. After 25 years of timing my own incidents, I can tell you the minutes hide in detection and diagnosis.

To cut MTTR, you first have to break it apart.

MTTR isn’t one number

“Mean time to resolve” lumps together several very different phases. Split it:

• Time to detect (TTD): broke → someone or something noticed.
• Time to acknowledge (TTA): alert fired → a human is on it.
• Time to diagnose: on it → we know what’s wrong.
• Time to mitigate: know what’s wrong → customer pain stops.
• Time to resolve: mitigated → fully fixed and verified.

Measure these separately. The phase that dominates your incidents is where to spend your effort — and for most teams it’s detect plus diagnose, not the fix.

Attack time to detect

The cruelest minutes are the ones where the system is broken and nobody knows. Shrink them:

• Alert on symptoms, not just causes. A CPU alert tells you a machine is busy; a “checkout success rate dropped” alert tells you customers are hurting. Symptom-based alerts on what customers actually experience catch incidents your cause-based alerts miss entirely.
• Tighten the slow alerts. If your latency alert needs five minutes of breach before firing, that’s five minutes of guaranteed blind time. Tune for impact.
• Watch the gap. In every postmortem, record the time between breakage and detection. A consistently large gap is your single biggest MTTR opportunity.

Attack time to diagnose

This is usually the fattest slice and the one AI helps most. Diagnosis is slow because a tired human is reading dashboards, correlating a timeline, and forming hypotheses one at a time. Speed it up structurally:

• Make “what changed” instantly available. Most incidents are caused by a change. A single view of recent deploys, config changes, and feature-flag flips, timestamp-aligned with the alert, collapses diagnosis time dramatically.
• Put runbooks one click from the alert. The alert should link to its runbook. Hunting the wiki at 3 AM is pure wasted MTTR.
• Pre-build the dashboards. If you’re assembling the right graphs during the incident, you’ve already lost minutes. The diagnostic view should exist before you need it.

Attack time to mitigate

Separate stopping the bleeding from fixing the cause. A practiced rollback, a feature-flag kill switch, or shedding load buys you breathing room while you diagnose calmly. Teams that can mitigate fast turn a panicked SEV1 into a controlled SEV2. Build and rehearse these levers in advance.

Don’t optimize a number into a lie

A warning from experience: when MTTR becomes a target, people game it. Incidents get closed early and reopened, or borderline events never get declared so they don’t count. Watch for those behaviors. MTTR is a diagnostic to find slow phases, not a scoreboard to win. Pair it with incident count and severity so a “great MTTR” that’s actually under-reporting shows up.

Where AI compresses the slow phases

Since diagnosis is usually the bottleneck, that’s where AI pays off most.

Reading the firehose. At 2 AM a model reads more logs than you can. Paste the alerts, a slice of logs, and recent changes:

“Summarize this active incident in 5 bullets, give the top 3 hypotheses ranked by likelihood, and for each give one read-only command to confirm or rule it out. Suggest nothing that changes state.”

You get a structured starting point in seconds instead of staring at dashboards forming hypotheses serially.

Correlating the timeline. AI is excellent at spotting the boring change three layers down — the cert that rotated, the pool size that changed — that a human with tunnel vision misses. Give it the alert start time and the change history and ask what changed closest to the symptom and by what mechanism.

Drafting comms in parallel so the investigation never pauses to write prose, keeping the whole response moving.

The guardrail never changes: AI reads and reasons, humans run commands. The safest-first ordering means a confident-but-wrong suggestion is read-only and harmless.

We keep incident-response prompts built around this flow, and the Incident Response tool turns symptoms into a risk-classified, safest-first plan that directly attacks your diagnosis time.

Where to start tomorrow

Pull your last ten postmortems and tag each phase’s duration. Whichever phase wins, fix that one — adding symptom alerts if it’s detection, building a change-view and AI triage if it’s diagnosis, rehearsing mitigation levers if it’s the fix. Don’t optimize the phase that feels exciting; optimize the one the data says is slow.

AI triage shortens diagnosis but does not replace verification. Confirm every recommendation against your own systems before acting.