# Trying to calculate MTTD (Mean Time To Detect)
**URL:** https://discuss.elastic.co/t/trying-to-calculate-mttd-mean-time-to-detect/384517
**Category:** Elastic Security
**Created:** [January 13, 2026, 5:35pm UTC](https://discuss.elastic.co/t/trying-to-calculate-mttd-mean-time-to-detect/384517 "2026-01-13T17:35:57Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@YousefNein](https://discuss.elastic.co/u/YousefNein)
#### Post date: [January 13, 2026, 5:35pm UTC](https://discuss.elastic.co/t/trying-to-calculate-mttd-mean-time-to-detect/384517/1 "2026-01-13T17:35:57Z")
Hello all,
I have been trying to calculate the MTTD, which consists of the difference between the case creation date and the first update of the case. However, when updating the case, the `updated_at` field gets updated as well.
However, any update in the case is available in the GUI.
---
### Author:  [@Tortoise](https://discuss.elastic.co/u/Tortoise)
#### Post date: [January 14, 2026, 7:14am UTC](https://discuss.elastic.co/t/trying-to-calculate-mttd-mean-time-to-detect/384517/2 "2026-01-14T07:14:31Z")
Hello @YousefNein
As per the requirement , i think you can use below formula to calculate the correct time as per your requirement of MTTD :
Sample Data Considered of 1 Case :
Corresponding Data in Dataview :
User below formula :
```auto
min(cases-comments.created_at) - min(cases.created_at)
```
Output :
Thanks!!
---
### Author:  [@YousefNein](https://discuss.elastic.co/u/YousefNein)
#### Post date: [January 14, 2026, 8:00am UTC](https://discuss.elastic.co/t/trying-to-calculate-mttd-mean-time-to-detect/384517/3 "2026-01-14T08:00:18Z")
Thanks, @Tortoise that will do. However, it will rely on the analyst not forgetting to write a comment. Do you know how to write a request to Elastic to add a “first\_updated\_at” field?
---
### Author:  [@Tortoise](https://discuss.elastic.co/u/Tortoise)
#### Post date: [January 15, 2026, 6:20am UTC](https://discuss.elastic.co/t/trying-to-calculate-mttd-mean-time-to-detect/384517/4 "2026-01-15T06:20:09Z")
Hello @YousefNein
What I calculated works only for a single case. The same approach does not work when we look at multiple cases together.
In Cases there are multiple child records (comments, status changes, user actions) created for each case, and they are linked indirectly using reference-style fields. Because of this structure it becomes hard to reliably identify when the _first_ status change or triage action happened for each case across the dataset.
So we need a different approach for multi-case metrics like MTTD. I found a similar enhancement request for Alerting , maybe a similar enhancement would be needed for Cases to support these kinds of metrics ?
>
>
> Several clients using the Security Stack in Elastic have requested the ability t…o track their user's activity when triaging and escalating the security alerts that have triggered in their environment. That way, the managers are able to generate metrics towards their security team's internal response time on detections, triage, escalations, etc.
>
> Currently, several customers have been utilizing other tooling such as ServiceNow to perform this task, but this would still require the ServiceNow integration to push out the Security Logs. The closest thing that Elastic currently provides is several fields that are generated when an open security alert is 'Assigned' to a Kibana user. This will generate the kibana.alert.workflow\_\* fields. As it stands, this workflow process could be expanded upon. When a user is assigned to an alert, this is written to the 'kibana.alert.workflow\_user' field. However, the value that is written is the user's Kibana UUID, not a written human name, which does not hold any context for those reviewing this information. Additionally, every time the user updates the status of the Alert (Open / Acknowledged / Closed), the timestamp for when the user does this is recorded in the 'kibana.alert.workflow\_status\_updated\_at' and 'kibana.alert.workflow\_status' fields. But every time this is changed, the field value is overwritten, which removes any previous audit information that was present.
>
> As it stands, the request would be to add a section under the Rules Management tab in the Security Stack to track this activity and be able to perform calculations. If done accordingly, it should be possible to track to following metrics for every user that is actively working the Security Alerts page:
>
> \- Mean Time to Detect (MTTD) - time the alert was detected versus the time it was opened
> \- Average Alert Handling - amount of time it took for the Analyst to 'get' to the alert, or initial assignment time after alert creation
> \- Dwell Time - time it took for an alert to fire
> \- Mean Time to Triage (MTTT) - time it took to Acknowledge the alert or otherwise escalate to a Case for further investigation.
> \- Mean Time to Close (MTTC) - time it took for the Analyst to open the alert and when that Analyst Closed the alert.
Thanks!!
---
### Author:  [@YousefNein](https://discuss.elastic.co/u/YousefNein)
#### Post date: [June 18, 2026, 12:00pm UTC](https://discuss.elastic.co/t/trying-to-calculate-mttd-mean-time-to-detect/384517/5 "2026-06-18T12:00:58Z")
[https://medium.com/p/7ea5f504a616?postPublishedType=initial](https://medium.com/p/7ea5f504a616?postPublishedType=initial)
I have created a method to calculate MTTD
I hope it helps!