Overview
Every incident created on Rootly can be marked with a set of properties. These properties can either be built-in or custom. Incident properties play a key role during incident management as they:
- help characterize each incident (e.g. kind = normal)
- can be used as trigger events (e.g. Status Updated)
- can help define run conditions (e.g. Severity is SEV0)
- can be used to filter metrics
- can be referenced using Liquid syntax
Fixed Properties
Fixed properties cannot be customized. They are created as-is by Rootly and are restricted on purpose to enforce a certain level of standard across the platform.
Incident Kind
The kind property is used by Rootly to identify the classification of incidents that are being created. This field cannot be customized and is determined at the time of incident creation.
| Kind | Description | Data Value |
|---|---|---|
| Incident | These are the most common incidents teams create. They are declared via the /rootly new Slack command. | normal |
| Sub Incident | These are child incidents that can be created under any normal incident. They are declared within an existing incident channel via the /rootly sub Slack command. | normal_sub |
| Test Incident | These are equivalent to a normal incident, but are used for testing purposes. Test incidents cannot be published on status pages. They are declared via the /rootly test Slack command. | test |
| Sub Test Incident | These are equivalent to a normal sub incident, but used for testing purposes. Sub test incidents also cannot be published on status pages. They are declared within an existing test incident channel via the /rootly sub Slack command. | test_sub |
| Backfill Incident | These are incidents that are added after an incident has already been resolved. When a backfill incident is declared, all workflows that trigger on Incident Created will not be run. They are declared via the /rootly new Slack command and with the Backfill Incident selected. | backfilled |
| Scheduled Maintenance | These are “incidents” that can be declared to planned maintenance cycles. They have their own unique statuses and other properties. They are declared via the /rootly maintenance Slack command. | scheduled |
Incident Status
Incident status is a key component that drives incident response processes. As with the other properties in this section, status is also fixed and cannot be customized.
| Kind | Description | Data Value |
|---|---|---|
| Triage | The triage status is used for issues that have not been confirmed as an incident. To declare an incident in the triage status, simply check the Mark as In Triage checkbox when creating an incident. | in_triage |
| Started | This marks the official start of an incident. You can progress an incident from the triage status to started or declare an incident directly into the started status. | started |
| Mitigated | The mitigated status is used to signify that the incident impact has been halted. This is not the end of an incident. | mitigated |
| Resolved | The resolved status is used to signify the end of an incident. This is typically when retrospectives are created and active issue tickets are closed. | resolved |
| Cancelled | The cancelled status can be used at any point in the lifetime of an incident. It is typically used to mark a false-positive incident or close a duplicate incident. | cancelled |
| Scheduled | The **scheduled **status only applies to scheduled maintenance. It is used to indicate that the maintenance window has been planned and created. | scheduled |
| In Progress | The in-progress status only applies to scheduled maintenance. It is used to indicate that the maintenance window is currently active. | in_progress |
| Completed | The completed status only applies to scheduled maintenance. It is used to indicate that the planned maintenance has ended. | completed |
Configurable Properties
Configurable properties are built-in, but they can be customized.
Go to the dedicated property article to learn how to configure each property and reference them using Liquid syntax.
| Property | Description |
|---|---|
| Environments | This property allows you to characterize incidents by the environment that they are impacting. For example, incidents impacting PROD should take priority over incidents only impacting DEV. |
| Severities | This property helps you categorize the impact level of incidents. For example, SEV0 incidents should take priority over SEV3 incidents. |
| Incident Types | This property is often confused with the Kind property. Kind is an internal categorization used by the Rootly platform, while Type can be customized to your company’s incident categorization requirements. The usage of this property is very flexible. Some companies use this to distinguish UI bugs from API issues. Others use this property to distinguish internal outages from customer-facing incidents. |
| Incident Roles | This property helps define your responders’ responsibilities during an incident. For example, an Incident Commander will have different tasks from the Communications Lead. |
| Teams | This property lets you assign incidents to the responsible teams. For example, incidents relating to the product should go to the Product team. |
| Services | This property lets you flag the service components that are impacted. Impacted services can be reflected on status pages. |
| Functionalities | This property lets you flag specific functional behaviors that are interrupted during incidents. For example, the ability to cart an item, or the ability to log in. Similar to Services, Functionalities can be displayed on status pages. |
| Incident Causes | This property allows you to quickly categorize the root cause of incidents. This is particularly useful for identifying trends when analyzing historical incidents. |
Property order
The order of items within each property is the order the items are displayed when the property is used as a form field. The order of items is global, meaning that it will impact every person who interacts with the field.
You can customize the order of items manually, by dragging and dropping the items into your preferred order, or by sorting alphabetically.
Custom Properties
When the built-in properties are not enough to meet all your incident categorization requirements, teams can set up custom properties to further enhance their incident characterization.
Please see the Custom Fields page to learn more about creating custom incident properties.
Support
If you need help or more information about this integration, please contact support@rootly.com or start a chat by navigating to Help > Chat with Us.