Updating Incident Timestamps
Overview
Incident timestamps are crucial for accurately documenting events, enabling precise tracking and analysis of occurrences. Not only are incident timestamps essential for legal and compliance purposes, they are also the foundation to tracking the quality and efficiency of your incident response process.
Available Timestamps
Each Rootly incident comes default with the following timestamps:
| Name | Required? | Description | Liquid Variable |
|---|---|---|---|
| In Triage | No | Before an incident starts, it can go through a triage state. This timestamp is automatically logged when the incident enters the in_triage state. | {{ incident.in_triage_at }} |
| Started | Yes | This marks the official start of an incident. This timestamp is automatically logged when the incident enters the started state. | {{ incident.started_at }} |
| Detected | No | This marks the time when the response team is informed. For many teams, the time in which the incident starts is also the time in which their responder team is informed. There is no “detected” state, so this timestamp is NOT automatically logged out of box. Teams can manually set it OR automatically set it through workflows. | {{ incident.detected_at }} |
| Acknowledged | No | This marks the time when the response team acknowledges that they are looking into the incident. For many teams, this timestamp is often tied to when the first responder acknowledges the page through an on-call solution (e.g. Rootly On-Call, PagerDuty, Opsgenie, etc.). There is no “acknowledged” state, so this timestamp is NOT automatically logged out of box. Teams can manually set it OR automatically set it through workflows. | {{ incident.acknowledged_at }} |
| Mitigated | Yes | This marks the time in which the impact of the incident is halted. This does NOT signify the end of an incident. This timestamp is automatically logged when the incident enters the mitigated state. | {{ incident.mitigated_at }} |
| Resolved | Yes | This marks the time in which the incident is resolved and all systems are running as normal. This timestamp is automatically logged when the incident enters the resolved state. | {{ incident.resolved_at }} |
| Cancelled | No | This marks the time in which the incident is cancelled. This timestamp is automatically logged when the incident enters the cancelled state. | {{ incident.cancelled_at }} |
Updating Timestamps
Manually Via Slack
Timestamps can be updated through the Rootly Slack bot by using the /incident timestamps Slack command.
Manually Via Web UI
Timestamps can also be updated through the Rootly web UI from the Incident Details page.
Click on any timestamp at the top right hand corner of a specific incident.
A modal will pop up to allow you to edit each timestamp.
Automatically Via Workflow
By default, Rootly will automatically log the In Triage, Started, Mitigated, and Resolved timestamps when the incident cycle enters those corresponding states. For the timestamps that Rootly do not automatically log out of box (Detected and Acknowledged), you can use a workflow to automate the logging. This method will work with all timestamps.
To automate via workflow, you’ll want to trigger a workflow following a specific event that updates the the timestamp using the Update Incident workflow action
Then, use the following syntax in the Custom Field Mapping input textarea to systematically update the acknowledged timestamp.
ISO 8601 Format: YYYY-MM-DD HH:MM:ss +/-0X00
Example:
- 2024-07-26 16:07:46 -0400 means July 26, 2024 at 4:07PM in a timezone that is 4 hours behind UTC
Liquid syntax is supported in this input text area so you can dynamically set the time by referencing a Liquid variable.
Metrics Calculations
Each timestamp plays an important role in calculating the metrics of an incident across the overall organization. The following are the math behind each calculated value:
| Value | Format | Formula |
|---|---|---|
Time to Mitigation {{ incident.time_to_mitigation }} | Integer in hours | {{ incident.mitigated_at }} - {{ incident.started_at }} |
Mitigation Duration {{ incident.mitigation_duration }} | Integer in seconds | {{ incident.mitigated_at }} - {{ incident.started_at }} |
Time to Detection {{ incident.time_to_detection }} | Integer in hours | {{ incident.detected_at }} - {{ incident.started_at }} |
Detection Duration {{ incident.detection_duration }} | Integer in seconds | {{ incident.detected_at }} - {{ incident.started_at }} |
Time to Acknowledge {{ incident.time_to_acknowledge }} | Integer in hours | {{ incident.acknowledged_at }} - {{ incident.started_at }} |
Acknowledge Duration {{ incident.acknowledge_duration }} | Integer in seconds | {{ incident.acknowledged_at }} - {{ incident.started_at }} |
Time to Resolution {{ incident.time_to_resolution }} | Integer in hours | {{ incident.resolved_at }} - {{ incident.started_at }} |
Incident Duration {{ incident.duration }} | Integer in seconds | If resolved, {{ incident.resolved_at }} - {{ incident.started_at }}If not resolved, now - {{ incident.started_at }} |