EDR Metrics That Actually Matter: Beyond Alert Counts and Coverage Percentages

Ask most security teams how their EDR program is performing and the answer arrives as a coverage percentage and an alert count. Both numbers can look healthy while the program is quietly failing at the one thing it exists to do: catch an attacker faster than the attacker can do damage. A dashboard full of green checkmarks doesn't answer that question, and neither does a chart of alerts triaged per week.

The metrics that actually matter are the ones that survive being asked twice — once by a SOC lead trying to tune detection logic, and once by a board member or auditor asking whether the spend on the platform is buying anything real. Most vanity metrics fail the second ask.

The metrics worth reporting

• Mean time to detect (MTTD) — from initial compromise activity to the first actionable alert, not from alert to acknowledgment
• Mean time to contain (MTTC) — from alert to the offending host actually being isolated, not just flagged
• True positive rate on high-severity detections — what fraction of the alerts that page someone at 2am turn out to be real
• Sensor health as a trend, not a snapshot — endpoints silently aging out of coverage matter more than the point-in-time percentage
• Dwell time on confirmed incidents — how long an adversary had hands-on-keyboard before detection, independent of how fast the response was once triggered

Why alert volume and coverage percentage mislead

Alert volume rewards noisy detection logic and penalizes tuning. A team that spends a quarter suppressing false positives will show a falling alert count that looks, at a glance, like reduced vigilance rather than the improvement it actually is. Coverage percentage has the opposite problem: it's a snapshot that says nothing about the endpoints that checked in successfully yesterday and have been silent since. Both numbers are easy to report and easy to game, which is exactly why they show up on every dashboard and answer almost nothing.

A coverage percentage tells you what the platform reported last time it checked in. A dwell-time trend tells you whether the program is actually getting better at its job. Only one of those survives a real incident.

Making the metrics defensible

None of these numbers mean much reported in isolation or produced once a quarter for a slide. MTTD and MTTC need a consistent, documented definition of their start and end points — teams that quietly redefine "detection" as "alert generated" instead of "first indicator of compromise present in telemetry" post better numbers without catching anything faster. Dwell time requires actually reconstructing the incident timeline, not estimating it after the fact. And every one of these metrics is stronger evidence for an auditor or a board than a coverage snapshot, because it shows the program responding to real events rather than reporting on its own configuration.

• Fixed, written definitions for MTTD and MTTC start/end points, applied consistently across every incident — not redefined case by case
• A trend line, not a single figure, for every metric that matters — one quarter tells you almost nothing
• Metrics broken out by detection source and business unit, since a fleet-wide average hides where the program is actually weak
• Post-incident timeline reconstruction as a standing practice, not a one-off exercise reserved for the worst events

The goal isn't a longer report. It's a smaller set of numbers that can't be improved by simply reporting less, and that answer the question a coverage percentage never could: if something real happens tomorrow, how fast do we actually catch it, and how fast do we actually stop it.