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

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.

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

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

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
Environments	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.
Severities	This property helps you categorize the impact level of incidents. SEV0 incidents should be handled with priority over SEV3 incidents.
Incident Types	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.
Incident Roles	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 are 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.
Functionalities	This property lets you flag specific functional behaviors 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.
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

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.

​

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.