When a critical error lands in production, your team needs an answer immediately: How bad is this, and who needs to drop what they're doing? A clear incident severity level system answers that question. SEV-1 means your service is down; SEV-5 means a non-critical feature is glitchy. Understanding the difference between incident severity levels SEV-1 through SEV-5 isn't just bureaucracy—it's the backbone of effective incident response and triage. Without it, teams either over-respond to minor issues or under-respond to genuine crises. In this post, we'll walk through a standard severity framework and show how error tracking with context (like affected users and stack traces) informs your severity call in real time.
Most mature teams use a five-level framework. Each level carries a response expectation: severity determines notification urgency, who gets paged, how long you can take to fix it, and whether a postmortem is required. Your exact definitions may vary, but the principle is the same: standardize how you classify so everyone responds the same way.
SEV-1: Complete Service Outage
SEV-1 is all-hands-on-deck. The service is down, unavailable, or fundamentally broken for all (or nearly all) users. Revenue is at risk. Examples: authentication is completely broken, the API is returning 500s for every request, the database is offline.
Response: Page on-call immediately. Drop everything. Declare a war room. Your target is resolution within minutes, not hours.
Detection signal: Error rate above a threshold (e.g., 50%+ of requests failing), or a sudden spike in critical errors affecting dozens of users simultaneously. Error tracking platforms help here—if LightTrace shows your error volume spiking to 10× normal in 60 seconds, that's your signal.
A single critical error affecting a few users might not be SEV-1, even if it's in your core login flow. Be precise: SEV-1 is widespread impact. A regression that breaks login for 60% of requests is SEV-1; a bug that breaks login for 3 specific users with unusual configuration is likely SEV-3.
SEV-2: Major Degradation, Partial Outage
SEV-2 means a significant part of the service is broken or severely degraded. Some users can still function, but the core experience is impaired. Examples: payment processing fails for Stripe customers (but not PayPal), search is down but browsing works, reports take 10 minutes instead of 10 seconds.
Response: Page on-call within 15 minutes. Formal incident channel. Your target is stabilization within the hour, root cause within 4 hours.
Detection signal: Error rate 10–50%, or critical errors affecting 5–20% of users, or latency jumping by 5–10×. An error budget breach is often your trigger—if your error SLO permits 0.1% failures per month and you're burning that in an hour, it's SEV-2 territory.
SEV-3: Moderate Issue with Workaround
SEV-3 affects a meaningful subset of users or functionality, but a workaround exists or the impact is not critical to business. Examples: a background job fails for 100 users but they can retry manually, an advanced filter on a dashboard is broken but simple search works, an email notification is delayed.
Response: Create a ticket. Assign it within an hour. Target resolution within a business day.
Detection signal: Error rate 1–10%, or errors affecting specific user segments (e.g., users in a certain region or on a certain plan). LightTrace's fingerprinting and tagging features help isolate these patterns—if you see 50 PaymentGatewayTimeout errors for users in Japan in the last 30 minutes, you've got SEV-3.
SEV-4: Minor Issue, Low User Impact
SEV-4 is a real bug, but it's cosmetic or affects a small, non-critical flow. Examples: a typo in an error message, a deprecated API endpoint returns the wrong HTTP status code, a sidebar widget fails to load but the main page works.
Response: Log it. Add to backlog. No page. No SLA.
Detection signal: Isolated errors, low repeat rate, or a single user reporting flakiness. If you see 2 errors in a million requests from one user over a week, it's likely SEV-4.
SEV-5: Cosmetic or No Impact
SEV-5 errors don't affect users or are so rare they're not worth your time immediately. Examples: a console warning in a third-party analytics library, a network timeout on a prefetch request that has a fallback, an old deprecation warning from a dependency you're planning to update.
Response: None. Ignore or batch into cleanup sprints.
Detection signal: Zero user impact, or impact only in development/staging. One-off errors that don't repeat.
How to Classify in Practice
Here's the decision tree: Start with user impact. Is the production service broken? If yes, how many users are affected—all, most, some, or a few? Then add business context: Is this in your core flow (payments, auth, search) or peripheral (notifications, analytics)? Finally, check repeatability and scope.
Error rate > 50% across the service?
YES → SEV-1
NO → Does it affect core business functionality?
YES → SEV-2 (if 10–50% rate) or SEV-3 (if 1–10% rate)
NO → SEV-3 (if 1–10%) or SEV-4 (if < 1% or isolated)
→ SEV-5 if truly zero user impact
The best teams instrument their errors so the severity classification is obvious from the data. You're adding tags for severity at ingest time: affected_users, error_type, service, region. Then in your dashboard, you can slice on those dimensions instantly. Instead of opening Grafana, running five queries, and guessing, you see: "This DatabaseConnectionTimeout has affected 47 customers across US and EU regions in the past 2 hours." That's SEV-2 language right there.
Automate where you can. Set up alert rules that notify on-call when a new issue appears or error frequency crosses a SEV-2 threshold, so the team sees regressions without being woken up for noise. LightTrace lets you define new-issue and event-frequency alert rules delivered by email—so you're not guessing at severity; your monitoring is telling you.
Common Classification Mistakes
Confusing severity with priority. SEV-4 can be high priority (fix it first thing Monday). SEV-2 might be low priority (it's a transient network hiccup that resolved itself). Severity is impact; priority is scheduling.
Assuming rare errors are low severity. A crash that affects 2% of Android installs might be rare in raw count but high impact. Classify by percentage, not absolute count.
Forgetting to reassess. An error that was SEV-3 at 2 a.m. might become SEV-2 by 9 a.m. if it's still happening and you're in peak hours now. Severity changes as context changes.
Overcomplicating the framework. You don't need SEV-1a and SEV-1b. Five levels are enough. If you're arguing about SEV-2 vs. SEV-3, that's a communication gap, not a framework gap.
Using Severity in Your MTTR Workflow
Once you've classified, severity drives your incident response SLA. SEV-1 might require acknowledgment within 5 minutes; SEV-2 within 15; SEV-3 within 1 hour. Your error tracking tool should make this visible: When you open an issue, you should see all signals that informed your severity—stack traces, affected user count, error rate, and whether this error has a linked GitHub incident or runbook. LightTrace surfaces all of that, so you're not hunting through Slack or your wiki to remember what a DatabaseDeadlock means. You can attach a runbook link to an error fingerprint, and every time that error lands in your dashboard, you see the playbook instantly.
The goal isn't perfect classification—it's consistency. If your team agrees that a 5% error rate in a critical service is SEV-2, then everyone responds the same way, and you're predictable. That predictability builds trust and reduces chaos.
Start tracking errors in minutes
Start tracking error severity and impact metrics with LightTrace. Sign up free, point a Sentry SDK at your LightTrace instance, and see how error context transforms your incident response. No credit card required.