I'm setting up monitoring for our security alerts and want to start tracking MTTD with the data from Elastic Endpoint. The docs mention the data is there, but I'm not clear on the practical steps.
What's the recommended way to calculate this? Do you typically use a specific index pattern or a pre-built dashboard? I'm especially unsure about how to consistently define the "detection time" versus the "incident start time" from the event logs. Any pointers on the common pitfalls in this calculation would be really helpful.
Still learning.
I run SecOps for a 400-person SaaS company, and we've been on Elastic Endpoint for about two years, so I've beaten my head against these exact metrics.
**Core comparison for tracking MTTD in Elastic Endpoint**
**Data model gremlin**: The biggest pitfall is that "detection time" and "event time" are different fields, and they often differ by minutes or hours. You'll need to use `event.ingested` for when Elastic actually got the alert, not `@timestamp`. That mismatch is the root of most bad data.
**Dashboard effort**: The pre-built "Host Risk" dashboards are useless for this. You're building custom Lens visualizations or Kibana queries from scratch. Budget half a day to get your first working histogram of detection time deltas.
**Hidden filtering cost**: Calculating this across *all* alerts floods you with noise from low-severity stuff. You must build a filter for alert severity (we use 'medium' and above) and likely suppress endpoint-isolated events, or your "mean" time will be a useless three seconds.
**Pricing surprise**: If you're on a lower Elastic Cloud tier or self-hosted with limited resources, running these aggregate queries over 90 days of alert data can hammer your cluster performance. We had to increase our data tier's memory allocation by about 20% to run these on-demand without timing out.
My pick is to use Elastic Endpoint's data *if* you're already committed to the Elastic stack for the long haul. The data's there, but the work to get a reliable metric is all on you. If you're not, I'd instead point you to the open-source Wazuh dashboard, which has a more straightforward 'alert timestamp' field and a simpler query structure for these basic SecOps metrics. To make a clean call, tell us whether you need this for executive reporting (polished) or internal team metrics (functional), and if your Elastic cluster has headroom for extra aggregations.
FOSS advocate
Right, you're hitting the wall everyone does with this data. User1111 is spot on about `event.ingested`. The pre-built dashboards are marketing fluff, you have to build your own Lens visualization. Your main challenge will be filtering out the noise.
You asked about defining "detection time" versus "incident start time." In Elastic Endpoint, the "detection time" is almost always the `event.ingested` timestamp for the alert document itself. The "incident start time" is trickier, you need to look for the earliest `@timestamp` among the related process or network events that triggered the alert. They're often in different indices. You'll need to join data, which Kibana isn't great at.
For a practical step, start with a simple query filtering to your endpoint alert index and calculating the delta between the minimum `@timestamp` from the source events and the `event.ingested` of the alert. Do not include benign or informational alerts in your MTTD calc or you'll massively skew your numbers.
Migrate once, test twice.
Filtering out the noise is the real cost sink here. You can burn days of analyst time just sifting through false positives to get a clean dataset, which they never factor into the platform's TCO.
Your point about joining data across indices is the killer. That's where teams usually give up and just track the alert timestamp, making their MTTD look artificially good. If you can't reliably tie the alert back to the initial event, the metric is just for leadership slides.
Are you actually using that calculated delta for anything operational, or does it just go into a monthly report that no one acts on?
Show me the bill
You've gotten excellent technical advice already on the data fields. Let me add the community management angle: the biggest pitfall isn't the calculation, it's *socializing a consistent definition* for your team.
If one analyst uses `event.ingested` and another uses the alert's `@timestamp`, your metrics will be meaningless for comparison. Document your chosen method in a shared wiki page and get agreement before you build a single dashboard.
Otherwise, you'll have a beautiful Lens visualization that nobody trusts 😅 Are you planning to standardize this with your SecOps peers first?
Great advice here already. I'd add that you'll probably want to filter your index pattern to `logs-endpoint.alerts-*` to start. The trick is setting up a Lens calculation for the time delta where `event.ingested` is your detection time, and you'd use a minimum aggregation on the related `@timestamp` from the source events as your incident start.
The pitfall? That "minimum @timestamp" can be hard to reliably grab if the triggering events are in a separate index. Sometimes you have to settle for the alert's own `event.start` field as a proxy, just to get something consistent rolling.
Automate all the things
Forget the dashboards, focus on the data join. The advice on `event.ingested` is correct. The real operational cost is setting up a reliable link between the alert and the earliest event timestamp across indices.
If you can't get that join right, your MTTD is a vanity metric. Most teams I've seen default to using the alert's own `event.start` because building the correlation is too costly. That inflates your numbers, but at least it's consistent for internal trending.
Have you quantified the engineering hours needed to build versus maintain this calculation? That's your real ROI check.
—hd
Spot on about the pricing surprise. Even on Elastic Cloud's higher tiers, we hit performance cliffs when our detection volume spiked. Those aggregate queries over 90 days would time out until we added a runtime field to pre-calculate the delta at ingest.
Your point on filtering is critical. We also found we had to exclude a whole category of automated, routine alerts from our EDR tool. Otherwise, the "mean" was just measuring how fast our system could generate noise.
Keep automating!
You've hit the core challenge everyone faces. The advice on using `event.ingested` as detection time is correct, but the implementation is where it gets messy.
You'll need to start with the `logs-endpoint.alerts-*` index pattern. The practical step most teams settle for is using the alert's own `event.start` field as a proxy for the incident start time, because the cross-index join to find the true earliest event is brittle and resource-intensive. It's not perfectly accurate, but it gives you a consistent delta against `event.ingested` that you can trend internally.
The major pitfall is not the query, but agreeing on this definition with your team. If you later change the logic, your historical trend is broken. Document which fields you're using and stick with them, even if it's a proxy.
Mike
You're nailing the real cost here, and that question at the end is the gut check everyone should do. I've seen beautiful dashboards built to track this delta that just become a monthly screenshot for a leadership deck, with zero operational changes. It becomes performance theater.
The point about the metric being for leadership slides if you can't reliably tie back to the initial event is painfully accurate. The temptation is to pick the easy, consistent proxy field just to have a number to report, even if it's inflated. But that's when you have to ask: is trending that imperfect number still useful if it drives a conversation about reducing the proxy delta over time? Sometimes the imperfect but consistent metric can motivate internal process improvements, even if the absolute value is wrong.
What's your take - does the act of building the calculation, even with its flaws, ever force useful process changes that make the number better later? Or is it always just a reporting sinkhole?
Let's keep it real.
That's a good question about ROI. The engineering hours for the join can be huge. But maybe the bigger cost is when the join logic breaks silently. Your dashboard shows improvement, but it's just because the correlation stopped working.
If you default to `event.start` as a proxy, how do you label that on reports? Do you call it "MTTD" knowing it's inflated, or create a new term?