Skip to main content

​
Overview

Incident Types let you classify incidents by a taxonomy that matches how your organization thinks about incident categories — “UI Bug”, “API Failure”, “Security Event”, “Internal Outage”, “Customer-Facing”, or whatever grouping is meaningful to your team. Types are fully customizable: you name them, you pick the colors, you decide how many. Types are frequently confused with the Kind property. The distinction matters: Think of Kind as answering “what kind of incident is this structurally?” and Type as answering “what category does this incident fall into in our organization’s taxonomy?”.
Incident types configuration

​
How Incident Types Are Used

Like Severity, Type is a lever that other Rootly features pull on: Because Type drives so much automation, the shape of your Type taxonomy directly shapes how well your automation targets the right responders — an overly generic Type (“Bug”) lands every notification with everyone, while an overly granular one (“iOS Bug on Login Screen”) splinters routing until nothing has enough volume to justify its rule.

​
Choosing a Type Taxonomy

There’s no universal Type taxonomy — but there are patterns that work and patterns that don’t. Use these to design or audit your team’s list.

​
How Many Types

Most teams land on five to ten types. Fewer than five and Type becomes redundant with Severity (which you already have). More than ten and calibration breaks down — responders default to whichever Type is at the top of the picker. If you catch yourself creating a Type that answers “who owns this?” — that’s what Teams or Services are for. If you’re creating a Type that answers “how bad is this?” — that’s Severity. Type is for what kind of thing is broken, not who owns it or how urgently.

​
Single-Select vs Multi-Select

Type can be configured as single-select (one Type per incident) or multi-select (multiple Types per incident). Which you choose changes both the picker UX and the workflow conditions available:
  • Single-select is simpler to reason about. Responders pick one Type; workflows filter with is / is one of. Best when your Types are mutually exclusive (an incident is a UI Bug or an Infrastructure issue, not both).
  • Multi-select captures overlapping taxonomies. Responders can tag both “Security Event” and “Data Privacy” on the same incident; workflows filter with contains any of / contains all of. Best when Types represent aspects rather than exclusive categories.
Most teams start single-select and switch to multi-select only when they hit real overlap. Switching later is fine — historical incidents preserve their existing Type values.

​
Common Taxonomies

Focus on the technical shape of the incident.
Focus on how the customer experiences the incident.
Focus on which product area is broken. Best paired with Multi-Select so cross-product incidents can be tagged with all affected areas.

​
Field Type

Configure Type as either single-select or multi-select in Configuration → Incident Types. The setting affects every incident going forward — historical incidents keep their existing values.
Field type selector
Liquid syntax differs slightly between the two modes. Single-select uses {{ incident.types | get: '<attribute>' }} for the one value. Multi-select uses {{ incident.raw_types[index] | get: '<attribute>' }} where index references a specific Type in the list. The attribute reference below covers both.

​
Configuring Type Attributes

Each Type can be configured with the attributes below. All are available as Liquid variables for use in workflows, retrospective templates, and status page updates.
​
ID
string
required
Unique identifier assigned automatically by Rootly on creation. Not customizable. Used in Liquid references and API calls.
​
Name
string
required
The display name shown throughout the Rootly UI. Fully customizable — pick names that match your team’s operational vocabulary.
​
Slug
string
required
Auto-generated by lower-casing and hyphenating the name. Used in Liquid references and in workflow condition matches.
Slugs regenerate when you rename a Type. Anything referencing the old slug — workflow conditions, saved metrics dashboards, third-party integrations that filter by slug — needs to be updated after a rename.
​
Description
string
Additional context shown alongside the Type in the UI. Best used to remind responders what qualifies for each Type — e.g., “Any incident affecting customer-facing surfaces (web, mobile, API).”
​
Color
string (hex)
Six-digit hex color code used for Type-tinted UI accents and metrics-graph color coding. Pick colors that are meaningful and consistent — reserving red for security-adjacent Types, for example.
Rootly expects six-digit hex codes (e.g., #c4231c). Use a color picker if you’re not sure — color-hex.com is a common choice.
​
Slack Channels
array of Slack channels
One or more Slack channels linked to the Type. Linking alone doesn’t post to the channels — a workflow action (typically “Attached Types Channels”) reads this list and performs the notification.
​
Slack Aliases
array of Slack user groups
One or more Slack user groups (aka aliases) linked to the Type. Linking alone doesn’t invite users — a workflow action (typically “Attached Types Aliases”) reads this list and performs the invitation.
​
Notify Emails
array of email addresses
One or more email addresses linked to the Type. Linking alone doesn’t send email — a workflow action reads this list and sends the notification.
For workflow-driven use, most teams reference the flattened list:

​
Best Practices

  • Design Types for automation, not documentation. If a Type doesn’t drive at least one workflow condition, alert routing, or metrics filter, it’s just a label. Retire it after 90 days if it never gets used.
  • Keep Type distinct from Team, Service, and Severity. Type is what’s broken; Team is who owns it; Service is which component is affected; Severity is how bad it is. Overlapping Types with those dimensions leads to the same data being encoded four times.
  • Start single-select, switch to multi-select when overlap is genuine. Multi-select is more flexible but harder to filter in workflow conditions (you need contains any of instead of is). Only take the added complexity when you actually have overlapping taxonomies.
  • Colors should be intuitive. Reserve red for security / data integrity Types. Use warmer colors (orange, yellow) for customer-facing Types and cooler colors (blue, gray) for internal-only Types. Responders read the color before the label.
  • Attach Slack channels + aliases per Type, but require workflow actions to actually use them. Same principle as Severities. Keeps notification behavior explicit and auditable.
  • Audit quarterly. Look at Type usage over the last 90 days. Rare Types (<5% of incidents) either need a rename to broaden their reach or removal from the picker. Dominant Types (>40%) probably need to be split.

​
Troubleshooting

Confirm the Type is enabled under Configuration → Incident Types. Archived Types remain visible on historical incidents but don’t appear as options on new incidents. If it’s enabled and still missing, check whether team-level restrictions are in play — some teams scope which Types their responders can select.
Two common causes: (1) the workflow’s condition uses is on a multi-select Type field — switch to contains any of (see Workflow Conditions for the operator reference); (2) the Type slug was regenerated after a rename and the workflow still references the old slug. Rename-triggered slug changes are automatic; update the workflow condition to match the new slug.
Linking Slack channels to a Type doesn’t cause auto-invitation on its own — a workflow with an “Attached Types Channels” action is required. Check that a workflow exists, is enabled, and has run conditions that match the Type you’re testing. The Type-updated trigger is a good candidate for this workflow.
Working as designed. {{ incident.types }} returns a joined string; access individual Types via {{ incident.raw_types[0] | get: 'name' }} or iterate with {% for t in incident.raw_types %}...{% endfor %} when you need per-Type rendering.
Metrics query by the Type’s slug, and slugs regenerate on rename. Saved dashboards or reports that filtered by the pre-rename slug won’t match anymore. Update the dashboard filter to the new slug, or plan the rename around a natural retention boundary if that filter can’t be updated cleanly.

​
Frequently Asked Questions

Most teams land on 5-10. Fewer and Type becomes redundant with Severity. More and calibration breaks down (responders default to whichever Type is at the top of the picker). See Choosing a Type Taxonomy above for detail.
Kind is a fixed, system-defined property that controls structural behavior (test vs normal, backfill vs scheduled maintenance, etc.). Type is a customer-defined categorical property for your organization’s taxonomy. Kind is set once at creation and is immutable; Type can be changed anytime. See Incident Kind for the full Kind reference.
Yes. Type is fully mutable — change it via the incident details page or a workflow action. Changes are logged in the incident timeline. This is different from Kind, which is immutable after declaration.
Yes — Types belong to a Team. Each team maintains its own Type list, and the picker on an incident form shows the Types defined for that incident’s team. If your workspace uses multiple teams, define the Types each team actually uses; there’s no single org-wide Type list.
Historical incidents keep the Type value they were created with, even after the Type is deleted from the picker. Only new incidents lose access to the removed Type. For matrix overhauls, archive rather than delete so historical data stays readable.
Yes. Type is one of the most common fields used in workflow run conditions. See Workflow Conditions for the operator reference — Type is often used with contains any of in multi-select mode.
No. Test incidents (declared via /rootly test) are excluded from production metrics regardless of Type. This is a Kind-level behavior; see Incident Kind for the full exclusion matrix.

Incident Kind

The fixed counterpart — governs structural incident behavior. Read this to disambiguate Kind from Type.

Severities

The other most-used incident property. Type and Severity are the two dimensions most workflows filter on.

Workflow Conditions

Use Type in workflow run conditions to route different incident categories to different response processes.