Severity Criteria for Incident Settings
Learn about severity settings to help you prioritize and manage Critical, High,
Warning, and Informational incidents differently.
| Where Can I Use This? | What Do I Need? |
|---|
|
|
- One of the following licenses:
- Strata Cloud Manager Essentials for predefined check
exceptions
|
Custom incident settings in Strata Cloud Manager allow you to
control how incidents are raised, prioritized, and notified based on conditions such as
product, incident category, subcategory, and incident code. You can add severity as a
condition when you create or update a custom incident setting, giving you more granular
control over how you manage incidents of different urgency levels.
When you add severity as a condition, you can select one or more severity
levels—Critical, High, Warning, or Informational—and
apply specific actions to incidents that match those levels. For example, you can create
a setting that raises and sends notifications only for Critical incidents within a
particular category, while suppressing Informational incidents in the same category. You
can combine severity with existing conditions such as product, incident category,
subcategory, and incident code, or you can use severity as the sole filtering criterion
and leave other conditions set to Any. The severity condition applies to both
default incident settings and custom incident settings.
The severity condition works alongside the existing contextual filtering in the
custom settings workflow. When you select one or more severity levels, Strata Cloud
Manager dynamically filters the available incident categories, subcategories, and
incident codes to show only those that contain incidents matching your selected
severity. This contextual filtering reduces the number of irrelevant options and helps
you build more targeted settings efficiently.
Severity Filter in Settings Resolution
When multiple settings match an incident, Strata Cloud Manager applies
severity-based prioritization:
A setting with a specific severity filter (such as
[Critical]) takes priority over a setting with no
severity filter (Any severity) when the incident severity matches.
Settings with Severity = Any continue to match all
incidents regardless of severity.
For incidents with dynamic severity (calculated at runtime from
incidents), the setting matches based on the severity determined at the time
the incident is raised.
When you create or update settings, Strata Cloud Manager enforces the
following validation rules to prevent conflicting configurations at the same
hierarchy level.
Rule 1: Prevent Overlapping Severity at Same Hierarchy Level
Strata Cloud Manager ensures that you cannot create conflicting settings at
the same level with overlapping severity values.
Different action types: If the action_type
differs between two settings (such as one is “raise” and the other is
“suppress”), Strata Cloud Manager ignores any severity overlap and allows
the configuration.
Same action type with severity overlap: If both settings
have the same action_type and their
severity_filter values overlap (such as both contain
“Critical”), Strata Cloud Manager rejects the configuration.
Rule 2: Any vs. Specific Severity Overlap
When one setting has severity_filter = Any (matches all
severities) and another has a specific severity filter:
Rule 3: Prevent Exact Duplicates (Enhanced)
The duplicate detection check now includes severity_filter
as part of the comparison:
Same action type with disjoint severity ranges: If two
settings have the same action_type but non-overlapping
severity values (such as [Critical] vs. [High,
Warning]), there is no conflict and the configuration is
allowed.
The following table summarizes how severity overlap validation applies
across different setting combinations:
| # | Setting A | Setting B | Result | Notes |
| 1 | severity=[Critical], action=raise | severity=[High], action=suppress | Allowed | Different action type; severity overlap ignored |
| 2 | severity=[Critical], action=raise | severity=[Critical, High], action=suppress | Allowed | Different action type; overlap ignored |
| 3 | severity=[Critical], action=raise | severity=[Critical, High], action=raise | Not Allowed | Same action type; severity overlap (Critical) |
| 4 | severity=[Critical, High], action=raise | severity=[Critical, High], action=suppress | Allowed | Different action type; exact match ignored |
| 5 | severity=[Critical, High], action=raise | severity=[Critical, High], action=raise | Not Allowed | Same action type; exact duplicate |
| 6 | severity=ANY, action=raise | severity=[Critical], action=suppress | Allowed | Different action type; ANY ignored |
| 7 | severity=ANY, action=raise | severity=[Critical], action=raise | Not Allowed | Same action type; ANY treated as overlap |
| 8 | severity=ANY, action=raise | severity=ANY, action=suppress | Allowed | Different action type |
| 9 | severity=[Critical], action=raise | severity=[High, Warning], action=raise | Allowed | Same action type but disjoint severity ranges |
When settings with different action types match the same
incident, the suppress action takes precedence over the raise action.
