> ## Documentation Index > Fetch the complete documentation index at: https://docs.rootly.com/llms.txt > Use this file to discover all available pages before exploring further. # Incident Kind > Understand the Incident Kind property — the immutable classification that determines how an incident behaves, which workflows fire, and whether it appears on status pages. ## Overview The **Kind** property determines the classification and structural behavior of an incident at the time it is created. It governs workflow triggers, lifecycle expectations, status page eligibility, and whether the incident contributes to production metrics. Kind is a **fixed property** — it's immutable after declaration. Choosing the right kind at creation matters because there's no way to convert a Test Incident into a Normal Incident, or a Scheduled Maintenance into a standard incident, after the fact. Kind answers "what kind of incident is this structurally?" — distinct from [Incident Types](/configuration/incident-types), which answers "what category does this incident fall into for our organization?". Types are fully customizable; Kind is system-defined and fixed. *** ## Available Kinds | Kind | Description | Data Value | | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- | | **Incident** | Standard production incidents declared via `/rootly new`. These represent real operational events requiring coordinated response. They trigger normal workflow execution and are eligible for publication on status pages (when not cancelled). | `normal` | | **Sub Incident** | Child incidents created under a parent incident using `/rootly sub`. They inherit contextual linkage from the parent incident and are useful for tracking parallel workstreams or related issues within a broader event. Eligible for status page publication (when not cancelled). | `normal_sub` | | **Test Incident** | Training or simulation incidents declared via `/rootly test`. They behave functionally like normal incidents but are excluded from status page publication and production metrics. Primarily used to test workflows, integrations, and team processes safely. | `test` | | **Sub Test Incident** | Child incidents created under test incidents. Used exclusively for training and simulation. Not eligible for status page publication. | `test_sub` | | **Backfill Incident** | Retroactively documented incidents created after resolution has already occurred. Backfill incidents are automatically created in a **resolved** state. Workflows triggered on Incident Created still execute, but active lifecycle stages such as Started or Mitigated are skipped. Eligible for status page publication (when not cancelled). | `backfilled` | | **Scheduled Maintenance** | Planned maintenance windows declared via `/rootly maintenance`. These incidents follow a distinct maintenance lifecycle separate from normal incident statuses. Used to proactively communicate planned changes via status pages. | `scheduled` | | **Sub Scheduled Maintenance** | Child incidents created under scheduled maintenance incidents. These follow the same maintenance lifecycle as their parent scheduled incident. | `scheduled_sub` | Normal incidents default to **in\_triage** status when the team setting "Incidents must start in the In-Triage status" is enabled. Otherwise, they default to **started** status upon creation. *** ## Behavior Differences at a Glance Each Kind selects a different mix of behavior — knowing the mix up front prevents the most common mistakes (declaring a test incident that pages on-call, declaring a normal incident for a maintenance window). | Kind | Triggers Workflows | Counts in Metrics | Eligible for Status Page | Has Active Lifecycle (Started/Mitigated) | | ------------------------- | ------------------ | ----------------- | ------------------------ | ---------------------------------------- | | Incident (`normal`) | Yes | Yes | Yes (when not cancelled) | Yes | | Sub Incident | Yes | Yes | Yes (when not cancelled) | Yes | | Test Incident | Yes | No | No | Yes | | Sub Test Incident | Yes | No | No | Yes | | Backfill Incident | Yes (on creation) | Yes | Yes (when not cancelled) | No (created already resolved) | | Scheduled Maintenance | Yes | No | Yes | No (uses maintenance lifecycle) | | Sub Scheduled Maintenance | Yes | No | Yes | No (uses maintenance lifecycle) | *** ## Choosing the Right Kind * **Use `normal` (Incident)** for the vast majority of real production issues — anything you'd want metrics, retrospectives, and on-call paging for. * **Use `test`** when validating workflows, training a new team member, or running a tabletop. Test incidents fire workflows so you can verify automation end-to-end, but they don't contaminate metrics or page customers via status pages. * **Use `backfilled`** when documenting an incident that already happened and was resolved outside of Rootly. The incident lands in `resolved` status; workflows that key off Incident Created still run, but Started/Mitigated transitions are skipped because they're already in the past. * **Use `scheduled`** for planned maintenance windows you want to communicate via status pages. Scheduled Maintenance follows a different lifecycle (Scheduled → In Progress → Completed) — don't try to fit a maintenance window into the normal Started/Mitigated/Resolved flow. * **Use `normal_sub`, `test_sub`, or `scheduled_sub`** when tracking a parallel workstream under an existing parent incident. Sub-incidents inherit the parent's context and are tracked together. *** ## Best Practices * **Pick the kind carefully on creation — it's immutable.** If you accidentally declare a real production incident as a Test Incident, you'll need to cancel it and re-declare as `normal`. The metrics and status page implications of getting this wrong are non-trivial. * **Default to `/rootly new` for ambiguous situations.** A real incident accidentally tagged Test is invisible in metrics. A test accidentally tagged Normal is recoverable by cancelling. Err toward the recoverable failure mode. * **Lock down `/rootly maintenance` to operators who actually run maintenance.** Status-page-publishing Scheduled Maintenance incidents are customer-facing — limit who can publish. * **Use Sub Incidents for workstream tracking, not categorization.** If you find yourself creating sub-incidents to label severity or component, you want [Incident Types](/configuration/incident-types) or [Custom Fields](/configuration/custom-fields) instead. *** ## Troubleshooting Test incidents do trigger workflows by default — if you have a workflow that pages on-call on Incident Created without a Kind filter in its run conditions, it will fire for test incidents too. Scope the workflow to real incidents by filtering on Kind. If you want to page for both top-level incidents *and* sub-incidents, use `Kind is one of: Incident, Sub Incident` (which corresponds to `normal, normal_sub`). If you only want to page for top-level incidents, use `Kind is: Incident` (which corresponds to `normal`) — this excludes sub-incidents, which are often used for parallel workstreams under a parent that already paged. Check the incident's Kind. Test (`test`, `test_sub`) and Scheduled Maintenance (`scheduled`, `scheduled_sub`) kinds are excluded from production metrics by design. If the incident was accidentally created as a Test, cancel it and re-declare with `/rootly new`. Kind is immutable. The only path is to cancel the existing incident and declare a new one with the correct kind. If the incident has a long timeline you don't want to lose, document the original incident ID in the new one's description so the history stays traceable. By design — backfill incidents are created already in `resolved` state, so the Started lifecycle stage is skipped. Only workflows triggered on Incident Created run for backfilled incidents. If you need a workflow to run for backfills, key it off Incident Created and add a `Kind is backfilled` condition. *** ## Frequently Asked Questions No. The **Kind** property is immutable after an incident is created. It determines the incident's structural behavior, workflow triggers, and status page eligibility at creation time. If you need a different kind, you must create a new incident with the desired kind. For example, you cannot convert a **Test Incident** to a **normal** incident, or change a **Scheduled Maintenance** to a standard incident after creation. **Kind** is a fixed, system-defined property that controls how an incident behaves structurally (e.g., `normal`, `test`, `scheduled`). It cannot be customized and determines workflow execution, lifecycle, and status page eligibility. **Type** ([Incident Types](/configuration/incident-types)) is a configurable property that allows organizations to define their own categorization taxonomy (e.g., "UI Bug", "Infrastructure Failure", "Security Event"). Types are fully customizable and can be used for filtering, reporting, and workflow conditions, but they don't affect the fundamental behavior of the incident. Think of **Kind** as "what kind of incident is this structurally?" and **Type** as "what category does this incident fall into for our organization?" Yes. Test incidents trigger workflows just like normal incidents, allowing you to test workflow automation safely without affecting production metrics or status pages. However, test incidents are excluded from status page publication and production reporting. This makes test incidents ideal for: * Validating workflow configurations * Training team members on incident response * Testing integrations without production impact Backfill incidents are designed to document incidents retroactively — after they've already been resolved. Since the incident has already concluded, they are created directly in a **Resolved** state. Workflows triggered on **Incident Created** still execute for backfill incidents, but active lifecycle stages (like **Started** or **Mitigated**) are skipped because the incident is already resolved. No. Scheduled Maintenance incidents follow a separate lifecycle with dedicated statuses (**Scheduled**, **In Progress**, **Completed**). They cannot use standard incident statuses like **Started**, **Mitigated**, or **Resolved**. This separation exists because maintenance windows have different lifecycle requirements than unplanned incidents. *** ## Related Pages The companion fixed property — controls lifecycle stage and progression rules. Customizable categorization, distinct from Kind. The umbrella page for all incident properties and configuration.