Incident Kind

The Incident Kind property is the immutable classification that decides how an incident behaves, which workflows fire, and status page eligibility.

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, 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 or Custom Fields instead.

---

Troubleshooting

I declared a test incident but it paged my on-call

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.

A real incident I declared isn't showing up in metrics

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.

I need to change the Kind of an existing incident

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.

My backfilled incident's Started workflow didn't run

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

Can I change an incident's Kind after it's created?

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.

What's the difference between Kind and Type?

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) 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?”

Do test incidents trigger workflows?

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

Why are backfill incidents automatically resolved?

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.

Can scheduled maintenance incidents use standard incident statuses?

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

Incident Status

The companion fixed property — controls lifecycle stage and progression rules.

Incident Types

Customizable categorization, distinct from Kind.

Configuration Overview

The umbrella page for all incident properties and configuration.