Incident Configuration
Every incident created on Rootly can be marked with a set of properties. These properties can either be built-in or a customer property. 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 as metrics filters
- can be referenced using Liquid syntax
The following section lists out all of the incident properties that you can use to help you manage incidents.
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.
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.
The available incidents kinds are:
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 used for testing purposes. Test incidents cannot be published onto 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 onto 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 it's 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 /rootly maintenance Slack command. | scheduled |
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.
The available incidents statuses are:
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. This status does NOT apply to scheduled maintenances. | 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. This status does NOT apply to scheduled maintenances. This status does NOT apply to scheduled maintenances. | started |
Mitigated | The mitigated status is used to signify that the incident impact has been halted. This is not the end of an incident. This status does NOT apply to scheduled maintenances. | 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. This status does NOT apply to scheduled maintenances. | 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. This status does NOT apply to scheduled maintenances. | cancelled |
Scheduled | The scheduled status only applies to scheduled maintenances. 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 maintenances. It is used to indicate that the maintenance window is currently active. | in_progress |
Completed | The completed status only applies to scheduled maintenances. It is used to indicate that the planned maintenance has ended. | completed |
Configurable properties are built-it, but they can be customized. Below is a list of configurable properties that can be customized to fit your incident management process.
Please click into each property to find out how to configure each property and how to reference them via Liquid variables.
Property | Description |
|---|---|
This property allows you to characterize incidents by the environment that they are impacting. Incidents impacting PROD should be taken with priority over incidents only impacting DEV. | |
This property helps you categorize the impact level of incidents. SEV0 incidents should be handled with priority over SEV3 incidents. | |
This property often gets 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. | |
This property helps define your responders' responsibilities during an incident. An Incident Commander should have tasks that are different from the Communications Lead. | |
Teams | This property lets you assign incidents to their responsible teams. Incidents relating to the product should go to the Product team, while security incidents is best handled by the InfoSec team. |
Services | This property lets you flag the service components that are impacted. Impacted services can be reflected on status pages. |
This property lets you flag specific functional behaviours that are interrupted during incidents. E.g. the ability to cart an item, or the ability to log in. Like services, functionalities are also displayable on status pages. | |
This property allows you to quickly categorize the root cause of incidents. This is particularly useful for identifying trends when analyzing historical incidents. |
Sometimes the built-in properties are not enough to meet all your incident categorization requirements. For a fully bespoked experience, teams can set up custom properies to further enhance their incident characterization.
Please see the Custom Fields page to learn more about creating custom incident properties.
If you need help or more information about this integration, please contact [email protected] or start a chat by navigating to Help > Chat with Us.
