If you're preparing for a SOC analyst role, MTTR will come up in interviews. If you're already in one, your manager is almost certainly tracking it. It sounds like a simple metric — and the calculation is — but there are two different things people mean by it, and confusing them is the kind of error that makes you look underinformed in front of a senior analyst.
What MTTR stands for
MTTR most commonly stands for Mean Time To Respond in a SOC context. It measures the average time between detecting a security alert and taking a meaningful response action — closing it, escalating it, or containing it.
Occasionally you'll see MTTR used to mean Mean Time To Resolve, which includes the full remediation cycle — patching, account resets, system restoration. That's a different and much longer number, usually owned by incident response rather than L1 triage.
When your SOC manager says MTTR, they almost certainly mean respond, not resolve. Know which one is being discussed.
How it's calculated
The formula is straightforward:
MTTR = Total response time across all alerts ÷ Number of alerts
If you closed or escalated 40 alerts this week and the cumulative time across all of them was 400 minutes, your MTTR is 10 minutes per alert.
In practice, most SOC platforms calculate this automatically. What you're looking at is your personal figure versus the team average, and the team average versus the SLA target. Most L1 SLAs sit somewhere between 15 minutes and 1 hour per alert depending on severity tier and the organisation.
Why it matters
Every minute an active threat sits unresponded-to is a minute of potential damage. The cost of a breach correlates directly with detection and response time — organisations with longer response windows consistently pay more per incident. MTTR is the metric that directly measures analyst efficiency.
It tells a SOC manager three things:
- Are we meeting our SLAs?
- Are some analysts struggling with particular alert types?
- Is the volume of work sustainable at current staffing?
For you as an L1, it matters because it's often tied to performance reviews and progression timelines. Consistently poor MTTR with no clear explanation (difficult alerts, tooling issues, unusual alert volume) is a flag. Consistently fast MTTR with good accuracy is one of the clearest signals that you're ready for L2 responsibilities.
What affects your MTTR
Tool proficiency. If it takes you four minutes to navigate to the right dashboard every time, that adds up across a shift. The faster you are in your SIEM, the lower your per-alert time. This is one of the most improvable factors for a new analyst — it's not intelligence, it's muscle memory.
Runbook quality. Good runbooks tell you exactly what to check and in what order. A vague runbook — or no runbook at all — means every alert is an investigation from scratch. If you join a team with weak runbooks, volunteering to improve them benefits everyone and demonstrates initiative.
Alert context. An alert that includes the source IP, relevant log lines, asset owner, and threat intel summary takes less time to work than a bare alert with a hostname and an event ID. If your SIEM enriches alerts automatically, learn what's in the enrichment so you're not re-looking up things already in front of you.
Escalation decisiveness. New analysts often sit on alerts they're uncertain about — not wanting to escalate unnecessarily. But a slow, uncertain escalation is usually worse than a fast escalation that turns out to be a false positive. If it's above your confidence threshold, escalate it and document why. Your MTTR reflects the time to a decision, not the time to certainty.
What's a good MTTR for an L1?
It depends on the organisation, alert types, and shift structure. As a rough benchmark:
- Under 15 minutes for routine, clearly categorised alerts — known false positive patterns, auto-closed policy violations
- 15–45 minutes for standard triage — check the logs, check threat intel, make a verdict
- 45 minutes+ should be the exception, usually indicating either a genuinely complex case or a process problem worth examining
MTTR in interviews
When an interviewer asks "are you familiar with SOC metrics?" and you explain the distinction between MTTR-respond and MTTR-resolve, cite why it matters for SLA compliance, and name one factor that affects it — that's a complete, senior-level answer from someone who hasn't started yet. Most candidates just say "mean time to respond, which measures how fast we respond to incidents." You'll stand out.
For more on how MTTR fits into a real shift, see what a SOC analyst actually does all day.
Practice triage under a live timer. SOCentre's simulator tracks your MTTR on every alert so you can see exactly where your time goes — and where to get faster. Start training free — no card required.