Alert Severity
Understand how severity levels affect alert delivery and help prioritize your response.
Every alert in Sazabi has a severity level that indicates its urgency and impact. Chat assigns severity based on its analysis of the issue, considering factors like error rates, user impact, and system criticality.
Severity levels
Sazabi uses four severity levels, from most to least urgent:
Critical
Critical alerts indicate a complete outage or severe degradation affecting your users. These issues require immediate action, regardless of the time of day.
Examples:
- Production database is unreachable
- Authentication service is down
- Payment processing is failing for all users
High
High alerts represent significant impact that requires urgent attention. These issues affect a substantial portion of your users or functionality but may not be a complete outage.
Examples:
- Elevated error rates on a core API endpoint
- Significant latency degradation on checkout flow
- Partial service outage affecting one region
Medium
Medium is the default severity level for alerts. These issues represent moderate impact that should be addressed during normal working hours.
Examples:
- Increased error rates on non-critical endpoints
- Slow queries affecting dashboard performance
- Failed background job processing
Low
Low alerts indicate minor impact that can be addressed when convenient. These issues do not significantly affect user experience.
Examples:
- Elevated warning logs that do not indicate failure
- Non-critical scheduled tasks running slowly
- Minor configuration inconsistencies
Severity and delivery behavior
Severity levels influence how and when alerts are delivered to your team:
| Severity | Default delivery behavior |
|---|---|
| Critical | Immediate delivery to all configured channels, including any on-call escalation |
| High | Immediate delivery to primary channels (Slack, email) |
| Medium | Standard delivery during configured hours |
| Low | Batched or delayed delivery, no push notifications |
Delivery behavior can be customized in your project settings. The table above shows default behavior for new projects.
How severity is assigned
Chat determines severity based on:
- Blast radius: How many users or services are affected
- Functionality impact: Whether core features are broken vs. degraded
- Error characteristics: Rate, duration, and type of errors observed
- Historical context: How this issue compares to past incidents
You can override the severity assigned by the assistant when viewing an alert. This helps calibrate future severity assignments for similar issues.
Best practices
-
Trust the defaults initially. The assistant's severity assignments are based on what it observes in your logs and metrics. Let it run for a while before adjusting.
-
Calibrate over time. If you find yourself frequently overriding severity, provide feedback to help the assistant learn your team's priorities.
-
Configure delivery appropriately. Ensure critical and high alerts reach your on-call team, while medium and low alerts do not wake people up at night.
-
Review severity distribution. If most of your alerts are critical or high, you may have noisy alerting that leads to fatigue. If most are low, you may be missing important signals.