MTTR is a recovery problem first
Mean time to restore improves when teams find the right problem quickly, know who can act, and already have a recovery path. Adding alerts can help when a real gap exists. It often fails when the team already receives more pages than it can investigate with care.
I start by asking how the last few incidents actually recovered. Who noticed first? What signal was trusted? Where did people lose time? The answers usually point to ownership, runbooks, or noisy telemetry, not a missing threshold.
Make ownership boring and visible
Ambiguous ownership stretches every incident. If two teams argue about who owns a service during an outage, recovery waits on coordination instead of action.
Write ownership where responders already look: service catalog entries, on-call schedules, dashboards, and deployment metadata. Keep a named escalation path for business impact decisions. During an incident, people should not invent the chain of command from chat history.
Prefer signals that explain impact
Alerts that say “CPU is high” force responders to rebuild the customer story from scratch. Alerts that say which user journey failed, which dependency is unhealthy, and how wide the blast radius looks give them a starting theory.
Trim alerts that never change action. If nobody pages on a signal, or every page becomes a mute, remove or rewrite it. Keep a small set of customer-facing and dependency-facing checks that map to known recovery steps.
Practice the restore path
A runbook that has never been used under pressure is a draft. Short game days, failover drills, and restore tests reveal missing credentials, stale docs, and steps that only one person understands.
Automation helps when it removes waiting: standard rollback, traffic shifting, feature flag shutoff, or cache purge. Automation hurts when it hides state and nobody trusts the button. Keep the human decision close to the action, and make the action itself fast and reversible.