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.
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
Custom Field Mapping
ISO 8601 Format: YYYY-MM-DD HH:MM:ss +/-0X00Example:
- 2024-07-26 16:07:46 -0400 means July 26, 2024 at 4:07PM in a timezone that is 4 hours behind UTC
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 }} |
Troubleshooting
A timestamp won’t update
A timestamp won’t update
The timestamp may conflict with another field. For example, a mitigation time cannot occur before the incident starts. Update related timestamps to maintain chronological order.
The Slack timestamp modal didn’t appear
The Slack timestamp modal didn’t appear
You may not have run the command inside the incident’s Slack channel. Slack commands outside the incident channel cannot be mapped to an incident.
Some fields are missing from the modal
Some fields are missing from the modal
Certain timestamps only appear when the incident is in the corresponding lifecycle state. For example, Mitigated and Resolved timestamps appear only after those transitions occur.
I’m seeing scheduled timestamps instead of lifecycle timestamps
I’m seeing scheduled timestamps instead of lifecycle timestamps
The incident is a scheduled maintenance event. Scheduled incidents use Scheduled From and Scheduled Until instead of lifecycle fields.
Analytics don’t reflect updated timestamps
Analytics don’t reflect updated timestamps
Refresh the page and verify that all timestamps follow chronological order. Incorrect ordering may cause metrics to appear inconsistent.
Best Practices
- Align on timestamp definitions to avoid interpretation differences across teams.
- Use automation whenever possible to promote consistent and reliable data.
- Review timestamps during retrospectives to ensure accuracy before finalizing the incident.
- Maintain chronological order so that insights and dashboards remain accurate.
- Prefer the Web UI for bulk adjustments, especially when updating several timestamps.
- Update timestamps promptly to avoid confusion around when key actions occurred.