Glossary
Glossary

What Are Incident Severity Levels?

By Sazabi Team

Last verified on Nov 8, 2026.

Incident severity levels are a scale for ranking an incident by impact, so the response matches the damage: who is paged, how fast they must act, and who has to be told. There is no universal standard. NIST says an organization can best quantify the effect of its own incidents, and AWS says your organization defines the exact scope of each rating.

Two Official Examples

NIST SP 800-61 Rev. 2 gives functional impact categories as an example of what an organization might use:

CategoryDefinition
NoneNo effect on the ability to provide all services to all users
LowMinimal effect; all critical services still available to all users, but efficiency lost
MediumLost the ability to provide a critical service to a subset of users
HighNo longer able to provide some critical services to any users

NIST adds that rating incidents helps prioritize limited resources, and that the response should weigh business impact together with the effort to recover. Its recoverability categories run from Regular (predictable with existing resources) to Not Recoverable. Rev. 3 of the publication, from April 2025, supersedes Rev. 2, but this rating example comes from Rev. 2, so treat it as an example and not a requirement. See incident response lifecycle for how Rev. 3 changed the model.

AWS Systems Manager Incident Manager rates impact from 1 (Critical) to 5 (No Impact). Its sample scopes:

CodeNameSample scope
1CriticalFull application failure that impacts most customers
2HighFull application failure that impacts a subset of customers
3MediumPartial application failure that is customer-impacting
4LowIntermittent failures with limited impact on customers
5No ImpactCustomers not currently affected, but urgent action is needed to avoid impact

Notice the fifth level. A problem can be urgent before any customer feels it.

Writing Your Own

Start from impact on users, not from the technical symptom. An example scheme, which is illustrative and not a standard:

LevelTestResponse
SEV1A core flow is down or data is being lost for many usersPage on-call now, open an incident channel, name an incident commander
SEV2A core flow is degraded, or a subset of users is cut offPage on-call, update stakeholders every hour
SEV3A minor feature is broken or a workaround existsTicket, handled in business hours
SEV4Cosmetic or internal-onlyBacklog

Four habits keep it usable:

  1. Make each level testable. "Over 5% of checkout requests failing" beats "major impact."
  2. Allow raising and lowering. Severity changes as you learn. Record when and why.
  3. Tie levels to actions. If SEV2 and SEV3 trigger the same response, merge them.
  4. Write the escalation clock. NIST suggests defining how long to wait for a response before escalating, giving about 15 minutes as an example.

Severity feeds the on-call page, the postmortem criteria, and the MTTR targets you report against. Sort alerts before they reach a person with the guidance on alert fatigue.

Severity in Sazabi

Sazabi, an AI-native observability and security platform, gives every issue one of four severities, from least to most urgent: low, medium, high, and critical. The agent assigns it when the issue opens, with medium as the default. Delivery rules can match by severity to decide which issues reach which channels, and selecting high does not include critical, so scope the rule to both. The issues documentation describes the lifecycle. Related guides: reliability issues and latency spikes.

Frequently Asked Questions

What are incident severity levels?

A scale for ranking an incident by its impact, so the response matches it: who is paged, how quickly, and who is told. The number of levels and their names are the organization's choice.

What is the difference between severity and priority?

Severity describes how bad the impact is. Priority is the order of work, which also weighs how hard the recovery is. NIST advises prioritizing by business impact and the effort needed to recover.

What is a SEV1 incident?

Usually the label for the highest severity in a scheme that numbers levels from SEV1 down, such as a core service unavailable for many users. There is no standard, so your policy has to say exactly what qualifies.

How many severity levels should you have?

Few enough that people pick the right one under stress. NIST's example scale has four categories, and the AWS example has five. Define each in terms people can check, such as the share of users affected.

Sources

  1. NIST SP 800-61 Rev. 2 describes prioritizing incidents by business impact and recovery effort, with example functional impact categories; Rev. 3 supersedes it (accessed Nov 8, 2026)
  2. Table 3-2 functional impact categories (None, Low, Medium, High), Table 3-4 recoverability effort, rating incidents helps prioritize limited resources, and an escalation process with a wait of perhaps 15 minutes (accessed Nov 8, 2026)
  3. AWS Systems Manager Incident Manager rates impact from 1 (Critical) to 5 (No Impact) and lets the organization define the scope of each rating (accessed Nov 8, 2026)
  4. A playbook entry explains the severity and impact of its alert (accessed Nov 8, 2026)
  5. Sazabi issues have one of four severities (low, medium, high, critical), assigned by the agent when it opens the issue, with medium as the default (accessed Nov 8, 2026)
  6. Delivery rules can match issues by severity; selecting high does not include critical (accessed Nov 8, 2026)