Skip to main content

​
Overview

Severity is the property that expresses how bad an incident is. It’s the single number responders reach for first — “is this a SEV0 or a SEV2?” — because so much else in the response process keys off it: who gets paged, how urgently, whether the status page is updated, what the retrospective template looks like, and how the incident is counted in your metrics. Severity is a fixed, single-select property. Every incident carries exactly one severity value, and that value is fully customizable — pick the number of levels, their names, colors, and behavior that matches how your team actually calibrates impact.
Severity configuration in Rootly Web

​
How Severities Are Used

Severity isn’t just a label — it’s a lever that other Rootly features pull on: Because so much automation branches on severity, the shape of your severity matrix drives the shape of your response process. That’s why the picker below and the matrix-design guidance further down matter as much as the attribute configuration.

​
Which Severity Should I Pick?

Deciding severity under pressure is the hardest part of severity calibration — new responders default to SEV0 out of caution and burn out the team; old hands default to SEV2 out of habit and miss real emergencies. Use the picker below as a starting point when the answer isn’t obvious, then refine against your team’s specific severity matrix.
Your team’s severity matrix may weight impact dimensions differently (e.g., regulated industries treat data exposure as automatic SEV0; ad-supported businesses may treat revenue-blocking outages as SEV1 even at partial scope). The picker offers a common baseline; the final call belongs to the responder declaring the incident.

​
Designing Your Severity Matrix

There is no universal severity matrix — but there is a small set of patterns that work for most teams. Use these as a starting point, then adjust the wording to match your specific product and customer promises.

​
How Many Levels

Most teams land on four to five severity levels. Fewer than four and you can’t distinguish “everything is broken” from “some things are broken.” More than five and calibration becomes fuzzy — SEV4 and SEV5 stop being meaningfully different, and responders default to SEV3 for everything below the top tier.

​
Impact Dimensions

A well-calibrated matrix considers multiple dimensions of impact — not just “how many users are affected” but also what is affected and for how long. Common dimensions:
  • User scope — everyone, a large segment, a small segment, individual users
  • Feature scope — entire product, one workflow, one screen, edge case
  • Data integrity — data loss / corruption / exposure present or not
  • Workaround availability — none, painful, minor friction, invisible
  • Duration expectation — active, transient, self-resolving
Not every dimension needs to weight equally. A regulated financial-services company weights data integrity above everything; an ad-supported consumer app weights user scope more heavily. Explicit weighting is fine and often better than pretending your team treats all dimensions equally.

​
Response Commitments Per Level

Severity levels should tie to concrete response commitments so calibration isn’t just a name — it’s a promise. Common commitments to attach per severity:
  • Paging urgency — SEV0 pages all-hands immediately; SEV1 pages the owning team; SEV2 pages during business hours; SEV3 assigns without paging
  • Incident Commander required — SEV0/SEV1 yes, SEV2/SEV3 optional
  • First status-page update within — SEV0: 5 min · SEV1: 15 min · SEV2: 30 min · SEV3: not required
  • Retrospective required — SEV0/SEV1 always, SEV2 if user-visible, SEV3 optional
  • Executive notification — SEV0 immediately, SEV1 within an hour, SEV2/SEV3 in weekly summary
Documenting these commitments in a shared runbook — not just in your head — is what turns severity from a label into an operating agreement.

​
Example Matrices

Common for mid-market SaaS teams with a mix of enterprise and self-serve customers.
Adds a level explicitly for data-integrity events, which typically override user-scope considerations.
Fewer levels because customer-facing severity nuance doesn’t apply the same way.

​
Configuring Severity Attributes

Configure severities in Configuration → Severities. Each severity can be tuned with the following attributes. Every attribute is available in Liquid syntax 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 — most teams use SEV0, SEV1, SEV2, SEV3 or P1, P2, P3, P4.
​
Slug
string
required
Auto-generated by lower-casing and hyphenating the name. Used in Liquid references and stable across name changes.
​
Description
string
Additional context shown alongside the severity in the UI. Best used to remind responders what qualifies for each level — e.g., “Total outage or active data loss.”
​
Color
string (hex)
Hex color code used for severity-tinted UI accents and metrics-graph color coding. Convention: red for the highest severity, orange/yellow for middle tiers, blue/gray for the lowest.
Rootly expects six-digit hex codes (e.g., #c4231c for red, #ed8f17 for orange). 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 severity. Linking alone doesn’t post to the channels — a workflow action (typically “Attached Severity Channels” or “Notify Attached Slack 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 severity. Linking alone doesn’t invite users — a workflow action (typically “Attached Severity Aliases”) reads this list and performs the invitation.
​
Notify Emails
array of email addresses
One or more email addresses linked to the severity. 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

  • Calibrate quarterly. Look at the last 90 days of incidents and ask: did we call any of these wrong in retrospect? Adjust the matrix language, not just individual calls.
  • Don’t add SEV4/SEV5 until SEV3 is used regularly. Extra levels only work if you actually distinguish between them. If SEV3 is your effective floor, adding SEV4 just creates a level nobody uses.
  • Colors should be intuitive. Red for the top severity, orange/yellow for middle, blue/gray for the lowest. Don’t invent custom mappings — responders read the color before the name and calibration takes twice as long if the color contradicts convention.
  • Downgrading is fine; upgrading is expected. Encourage responders to over-page at SEV0 and downgrade within 15 minutes if scope narrows. Under-response at declaration is the failure mode you’re trying to avoid, not over-response.
  • Keep the picker open during on-call handoffs. Sharing the picker link (/configuration/severities#which-severity-should-i-pick) is one of the fastest ways to onboard new responders to the calibration model.
  • Attach Slack channels + aliases per severity, but require workflow actions to actually use them. This keeps notification behavior explicit and auditable in the workflow list rather than hidden in severity settings.
  • Test severity changes in a Test Incident first. If you rework the matrix or add a new severity, declare a /rootly test and walk the workflows through their branches before the next real incident hits the new definitions.

​
Troubleshooting

Confirm the severity is enabled (not archived) under Configuration → Severities. Archived severities 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 severity restrictions are in play — some teams scope which severities each team can declare.
Linking Slack channels or aliases to a severity does not cause auto-invitation on its own. You need a workflow with an “Attached Severity Channels” or “Attached Severity Aliases” action, keyed off a Severity Updated trigger or the initial Incident Created trigger. Check that the workflow exists, is enabled, and has run conditions that match the severity you’re testing with.
Metrics bucket incidents by the severity value at the time of the metric query — so if severity was changed mid-incident, the current severity is what’s counted (not the initial one). If you need historical severity data, query the incident timeline events, which record every severity transition with timestamps.
Confirm the color is a valid six-digit hex code starting with # (e.g., #c4231c, not c4231c or rgb(196, 35, 28)). Rootly won’t attempt to parse shorthand or non-hex color formats.
Two common causes: (1) the description field for each severity is empty or too vague — expand each severity’s description to name concrete example scenarios; (2) the picker on this page isn’t linked from your on-call runbook — add a link so responders reach for it during triage. Also review the last 30 days of incidents in a calibration meeting and identify which mis-calls the language could have prevented.

​
Frequently Asked Questions

Most teams land on four (SEV0–SEV3) or five (SEV1–SEV5). Fewer than four can’t distinguish emergency from major from moderate. More than five and the extra levels stop being meaningfully different in practice — see the Designing Your Severity Matrix section above for detail.
Yes, and it’s expected. Changing severity logs a timeline event with the transition timestamp, which downstream workflows can trigger off (via the Severity Updated trigger). Most teams see severity change one to two times per incident as scope becomes clearer.
In Rootly, severity is the built-in property. Priority (if you use it) is typically a custom field layered on top — often used to distinguish “how urgent is this to fix” from “how bad is this while it’s happening.” A minor bug with a big customer implication might be SEV3 severity but P1 priority. Rootly doesn’t ship priority as a built-in; add it as a Custom Field if you want it.
No. Test incidents (declared via /rootly test) are excluded from production metrics regardless of the severity assigned. This is enforced at the Kind level — see Incident Kind for the full behavior matrix.
Yes. Severity is one of the most common fields to filter on in workflow run conditions. The Workflow Conditions page has an interactive evaluator you can use to test severity-based conditions against a sample incident before wiring them into a real workflow.
Rootly’s severity list is org-wide, but teams can restrict which severities their responders declare. If you need genuinely different severity matrices per team (e.g., an infra team using P1–P4 and a product team using SEV0–SEV3), the current recommendation is to unify to one matrix and use naming that works for both — running two parallel matrices is confusing at the org level for metrics and executive reporting.
Deleting (or archiving) a severity leaves historical incidents referencing it intact — the incident keeps its original severity value even after the severity is removed from the picker. Only new incidents lose access to the removed severity. If you’re doing a matrix overhaul, archive old severities rather than deleting, so historical incident data stays readable.

Workflow Conditions

Use severity in workflow run conditions to route different severities to different response processes.

Incident Kind

The other fixed property — governs whether an incident counts in metrics regardless of severity.

Custom Fields

Add a priority field or other custom taxonomy on top of severity.