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 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.

Custom Field Mapping


{ "acknowledged_at": "<enter time value in ISO 8601 format>" }

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

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 }}`

Troubleshooting

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.

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

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.

Getting Started

Incident Management

Alert Management

On-Call Management

Automation & Workflows

Rootly AI

Configuration & Setup

Analytics & Retrospectives

Team & User Management

Communication & Notifications

Templating & Variables

Troubleshooting

Support

Updating Incident Timestamps

Overview

Available Timestamps

Updating Timestamps

Manually Via Slack

Manually Via Web UI

Automatically Via Workflow

Metrics Calculations

Troubleshooting

Best Practices

​Overview

​Available Timestamps

​Updating Timestamps

​Manually Via Slack

​Manually Via Web UI

​Automatically Via Workflow

​Metrics Calculations

​Troubleshooting

​Best Practices

Overview

Available Timestamps

Updating Timestamps

Manually Via Slack

Manually Via Web UI

Automatically Via Workflow

Metrics Calculations

Troubleshooting

Best Practices