Overview
Every incident created in Rootly is characterized by a structured set of properties. These properties define how an incident behaves, how it progresses through its lifecycle, how it interacts with workflows and automation, and how it appears in reporting and analytics. Incident properties serve several critical purposes:- Help characterize each incident (e.g.,
kind = normal) - Trigger workflow automations (e.g., Status Updated)
- Define conditional logic for workflow execution (e.g., Severity is SEV0)
- Enable filtering and segmentation of metrics
- Allow structured access through Liquid syntax
- Fixed Properties — system-defined and not customizable
- Configurable Properties — built-in but organization-customizable
- Custom Fields — fully defined and managed by your organization
Fixed Properties
Fixed properties are intentionally restricted to maintain lifecycle integrity, automation consistency, and reporting standardization across the Rootly platform.
Incident Kind
The Kind property determines the classification and structural behavior of an incident at creation time — whether it’s a real production incident, a test, a backfill, or a scheduled maintenance window. Kind is immutable after declaration and governs workflow execution, status page eligibility, and metrics inclusion. For the full kind reference (all seven kinds, behavior matrix, choosing the right kind, and Kind-related troubleshooting), see Incident Kind.Incident Status
The Status property defines the lifecycle stage of an incident — from Triage through Started, Mitigated, Resolved, Closed, or Cancelled. Status transitions are validated to preserve chronological and logical integrity. Scheduled Maintenance incidents follow a separate lifecycle (Scheduled / In Progress / Completed) with its own rules. For the full status reference (transition rules, timestamp validation, sub-statuses, the Scheduled Maintenance lifecycle, and Status-related troubleshooting), see Incident Status.Configurable Properties
Configurable properties are built-in fields that organizations can customize to reflect their operational structure, severity model, and reporting taxonomy.| Property | Description |
|---|---|
| Environments | Characterizes incidents by environment (e.g., Development, Staging, Production). Commonly used to prioritize production-impacting incidents and to filter metrics and workflow conditions. |
| Severities | Defines impact levels (e.g., SEV0–SEV3). Drives escalation logic, workflow triggers, and reporting analysis. |
| Incident Types | Custom categorization distinct from Kind. Allows organizations to define taxonomy such as UI Bug, Infrastructure Failure, Security Event, etc. |
| Incident Roles | Defines structured responder roles (Incident Commander, Communications Lead, etc.) to coordinate responsibilities during response. |
| Teams | Assigns ownership and organizational routing responsibility to teams or groups. |
| Services | Identifies impacted infrastructure components. Used for service-level reporting and status page communication. |
| Functionalities | Identifies impacted product capabilities (e.g., login, checkout). Enables feature-level transparency. |
| Incident Causes | Categorizes root causes to support retrospective analysis and long-term reliability improvements. |
Property Order
The ordering of values within configurable properties determines how they appear in dropdown menus and forms. Ordering is global and affects all users. You can:- Drag and drop values manually
- Sort values alphabetically
Custom Fields
When built-in properties are insufficient to meet your organization’s needs, you can create Custom Fields to extend the incident schema. Custom Fields allow you to:- Capture structured or unstructured metadata
- Apply validation and defaults
- Power advanced workflow automation
- Reference values using Liquid syntax
- Enforce organization-specific incident taxonomy
Frequently Asked Questions
Can I delete or modify fixed properties like Kind or Status?
Can I delete or modify fixed properties like Kind or Status?
No. Fixed properties (Kind and Status) are system-defined and cannot be modified, deleted, or customized. They exist to ensure consistency across the platform and maintain the integrity of workflow automation and reporting.If you need different categorization options, use Configurable Properties (like Incident Types) or Custom Fields, which can be fully customized to meet your organization’s needs.
Can I use custom fields in workflow conditions?
Can I use custom fields in workflow conditions?
Yes. Custom fields can be referenced in workflow run conditions and Liquid templates, allowing you to create sophisticated automation based on organization-specific data.Custom fields are accessible via Liquid syntax:This enables workflows to react to custom field values, trigger actions based on custom data, and include custom field information in notifications and integrations.
What happens if I change the order of configurable property values?
What happens if I change the order of configurable property values?
Property ordering is global, meaning changes affect all users immediately. When you reorder values (e.g., Severities or Environments), the new order appears in:
- Dropdown menus when creating or editing incidents
- Form fields across the platform
- Any interface where that property is displayed
Need help or have a question?Contact us anytime at support@rootly.com, use the
/rootly support Slack command, or visit Getting Help to start a chat.