> ## Documentation Index
> Fetch the complete documentation index at: https://docs.incident.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Severities

> Classify the level of impact an incident had using severities tailored to your organization.

Severities classify how bad an incident is, giving everyone a shared language for impact. When someone sees a Critical incident, they know to drop what they're doing; a Minor one can wait until working hours. That shared understanding is what lets you drive the right response, escalate to the right people, and compare incidents over time.

When you install incident.io, you start with three default severities:

* **Minor**: low impact, usually handled within working hours, and most customers are unlikely to notice.
* **Major**: significant impact that usually needs an immediate response, sometimes with a workaround in place.
* **Critical**: very high impact, like a full outage or a data breach, where immediate response is required.

These are a starting point, not a rule. Rename them, rewrite their descriptions, or add your own to match how your team thinks about impact.

## Managing severities

You can manage severities in [**Settings → Severities**](https://app.incident.io/~/settings/severities). Managing severities requires the **Manage organization settings** permission.

Each severity has:

* **Name**: what the severity is called, for example *Major*. Keep it short, since it appears anywhere an incident's severity is shown.
* **Description**: an explanation of when this severity applies. This is the most useful field to get right, because it's what helps a reporter pick the correct severity under pressure. A good description answers questions like: what's the likely impact on the business, what customer communications are needed, and who might need to be involved.

Severities are ranked from least to most severe, and you can drag them into the right order on the settings page, with the most severe at the top. The order applies everywhere in incident.io, so a Major always sits above a Minor wherever severities appear. That consistency is what makes severities comparable in [Insights](https://app.incident.io/~/insights) and reporting.

## Using severities

Once set up, severities show up throughout the incident lifecycle:

* **When declaring**: reporters pick a severity as they open an incident, setting expectations from the very first moment.
* **As things develop**: severity isn't fixed. Raise or lower it as you learn more, and everyone stays in sync with how serious the incident currently is.
* **To drive automation**: use severity as a condition in [workflows](/workflows), for example escalating to a wider group or notifying leadership only when an incident is Critical.
* **For reporting**: filter and group incidents by severity in Insights to understand trends, like whether major incidents are becoming more frequent.

## Tailoring severities by incident type

Severities are shared everywhere in incident.io, but you can adjust how they behave for a given [incident type](/incidents/incident-types). Within an incident type you can override a severity's description, hide severities that don't apply, and restrict who's allowed to set a particular severity. See the [severities section of incident types](/incidents/incident-types#severities) for details.