You are in control of your cookies

    Atlas uses strictly necessary cookies to keep you signed in. With your consent, we add anonymized product analytics, conversion attribution, and remembered preferences. Change your mind any time at /privacy/cookies.

    Off until you agree · Change it any time

    • NecessaryAlways on
    • AnalyticsOpt-in
    • MarketingOpt-in
    • PreferencesOpt-in
    Still loading. Try again in a moment.Still loading. Try again in a moment.Still loading. Try again in a moment.
    Atlas
    • All-in-one
    • Solutions
    • Compare
    • Pricing
    PricingGet started
    1. Atlas
    2. Guides
    3. Incident Severity Levels: How to Define SEV1 to SEV5
    October 26, 2026·9 min read·incident management, severity levels, on-call, service operations

    Incident Severity Levels: How to Define SEV1 to SEV5

    A severity scale decides how loudly to respond. Defined well, it removes argument during an incident. Defined badly, it is either ignored or abused.

    An incident severity level is a label that states how serious an incident is and, by agreement, what response it receives. A level translates a judgement about impact into actions: who is paged, who leads, who is told and how quickly an update is due.

    Severity is used under pressure by people who have little time. The scale therefore needs to be small, concrete and tied to what customers experience, not to how worried the responder feels.

    Common scales

    Several conventions are in common use. Many software teams use SEV1 to SEV4 or SEV1 to SEV5, where SEV1 is the most serious. Some add SEV0 above it for a catastrophic event. IT service management uses priority levels P1 to P5, derived from impact and urgency. Some teams prefer plain words such as critical, major, minor and low, which need no decoding. The convention matters less than having one and using it consistently.

    Atlas offers four presets: SEV1 to SEV5, SEV0 to SEV5, ITIL P1 to P5, and plain words such as Critical and Minor. You can edit the levels, their response targets and whether each one pages, or build your own with your own names and ranks.

    Write criteria a stranger could apply

    Each level needs criteria that two people would apply the same way. Tie them to customer impact and scope. The following is an illustration to adapt, not a standard.

    • SEV1, critical: a core service is unavailable or unusable for most customers, or there is confirmed loss or exposure of data. Respond immediately, page the responders at any hour, name an incident commander and update stakeholders on a short, fixed cycle.
    • SEV2, major: a core function is seriously degraded or unavailable for a significant group, or a major customer is blocked. Page the responders, and update on a regular cycle.
    • SEV3, moderate: a non-core function is degraded or a workaround exists. Handle during working hours unless it worsens.
    • SEV4, minor: a cosmetic or low-impact issue. Track as ordinary work.

    Separate severity from impact

    Two ideas are often merged. Severity says how seriously to treat the incident and who to wake. Impact says what customers experience: nothing, a degraded service, a partial outage or a full outage. They usually move together but not always. A full outage of an internal tool at midnight may be low severity. A quiet data exposure may have no visible customer impact and still be the most serious event of the year.

    Atlas records both. Severity drives who is paged. Impact drives what customers are told. Keeping them apart avoids the situation in which a team must misstate one to get the other right.

    Attach actions to each level

    A level without actions is a label. For each level, decide:

    • Whether it pages, and at what urgency. Atlas distinguishes pages that wake people and override quiet hours, notifications that do not, and records that notify nobody.
    • The target time to acknowledge and the target time to mitigate.
    • Whether a commander is required and which other roles are filled.
    • The update cadence and the audience for updates.
    • Whether a review is required afterwards.

    Changing severity during an incident

    Severity is a judgement based on what is known, and it changes as more is learned. Most incidents start lower and rise as impact is confirmed, and some start high and are stood down. Raise it readily and lower it only with evidence. Record each change on the timeline with the reason.

    When unsure, choose the higher level. Raising severity later loses time that standing down never costs. Each Atlas incident stores the rank it was declared at, so changing the scale later does not alter what an old incident meant.

    Mistakes to avoid

    • Too many levels. Responders cannot hold seven definitions in mind at three in the morning. Four or five is enough.
    • Criteria based on feelings. "Serious" is not a criterion. "More than a stated share of users cannot sign in" is.
    • Using severity to set priority in the ordinary backlog. Severity governs response, not planning.
    • Punishing a responder for declaring too high. That teaches people to under-declare.
    • Never reviewing the scale. After each incident, ask whether the level matched the experience.

    Keep reading

    • Incident management: the complete guide
    • The incident commander role
    • Designing an escalation path
    • Incident Management in Atlas
    • On-Call Management: Schedules, Escalation and Handover
    • Alert Fatigue: How to Cut Noisy Alerts and Protect On Call
    • On-Call Handover Checklist: What to Pass On at Shift Change
    • Incident Communication: What to Tell Customers and When
    • Free PDF tools
    • The all-in-one work OS

    FAQ

    Questions, answered.

    What is a SEV1 incident?
    In most scales SEV1 is the most serious level: a core service is down or unusable for most customers, or data has been lost or exposed. It receives an immediate response, a named commander and frequent stakeholder updates. Each organisation should write its own criteria.
    How many severity levels should we have?
    Four or five. More than that cannot be applied consistently under pressure, and fewer cannot distinguish between a response that wakes people and one that does not.
    What is the difference between severity and impact?
    Severity is how seriously to treat the incident and who to wake. Impact is what customers experience. Atlas records both, using severity to decide who is paged and impact to decide what customers are told.

    Ready when you are

    One workspace, not ten.

    Atlas replaces the stack with one platform for tasks, projects, CRM, contracts, e-signature, PDF tools, and analytics. Start free.

    Get started freeSee pricing
    AtlasWork, planned itself.

    The AI-native, all-in-one work platform. Tasks, projects, CRM, contracts, and analytics in one calm workspace.

    System status
    • SSO
    • SCIM
    • Two-factor sign-in
    • Audit log

    Product

    • Overview
    • PDF tools
    • Diagram tools
    • People & HR
    • Integrations
    • Marketplace
    • Pricing

    Resources

    • Guides
    • Glossary
    • Compare
    • Docs
    • API reference
    • Support
    • Changelog
    • Status

    Company

    • About
    • Careers
    • Press
    • Contact

    Legal & trust

    • Trust center
    • Security
    • Privacy
    • Terms
    • DPA
    • GDPR
    • SLA
    • Refunds
    • Google API data
    Atlas, a product by wrxstack.com·© 2026 wrxstack·All rights reserved
    PrivacyTermsSecurityStatus