Standardized event severity
- Latest Dynatrace
- How-to guide
Dynatrace aligns with the ITIL framework standard for IT management systems when classifying event and alert severity.
Severity is expressed as a numeric value from 1 (the most critical state) to 5 (purely informational event).
Severity levels
| Numeric value | Severity level | Description |
|---|---|---|
| Critical | Complete outage with direct customer impact. The system is down. For example: SSO is unavailable, users can't log in, or customer data is lost or exposed. |
| Major | Severe interruption of a service with significant customer impact. The service is operational but significantly degraded. For example: a large portion of users can't log in. |
| Minor | Slowdown, service degradation that affects the user experience without causing a full interruption. For example: login is very slow but functional. |
| Warning | A noticeable issue with no significant customer impact. |
| Informational | An event raised for informational purposes only, with no customer impact. |
Severity storage in Grail
Grail stores severity as a numeric value. You can query severity from individual davis.events using DQL:
fetch dt.davis.events| fieldsKeep event.name, event.severity
This returns a table of event names alongside their corresponding severity values. If an event source doesn't set severity, the field is empty.
Severity for events and problems
Single events
A single event carries exactly one severity value, or none if the event source doesn't set it.
Problems
A problem can group multiple events that carry different severities. Dynatrace applies the following aggregation logic:
- The problem inherits the highest (most critical) severity across all grouped events. For example, if a Minor (
3) event and a Critical (1) event are grouped into one problem, the problem's severity is Critical (1). - Severity can only increase, never decrease. Once a problem reaches a severity level, it permanently retains that level—even after the original conditions are resolved. The problem can only be closed.
The reason severity can increase but never decrease is to preserve historical reporting accuracy. If resolved problems were downgraded, a monthly report of Critical incidents would show incorrect data retroactively.
The severity column shows only Critical, Major, and Minor (levels 1–3).
Warning and Informational events appear in the event list and can be grouped into a problem by problem correlation, but they don't raise problems on their own.
Set severity for anomaly detectors
You can configure severity configuration in two ways:
-
When creating a new alert
- Go to
Settings > Analyze and alert > Alerts > All alerts. - Select Custom alerts.
- Select New alert to create a new alert.
- Go to the Advanced tab.
- Got to Add details > Create event template.
- In Event properties, set this key-value pair:
event.severity - <number from 5 to 1>. - Select Save.
- Go to
-
When editing an existing alert
- Go to Settings > Analyze and alert > Alerts > All alerts.
- Select Custom alerts.
- Select a custom alert to edit its settings.
- In Properties, add
event.severity - <number from 5 to 1>. - Select Save.
- Go to
Severity in workflows
When you configure a workflow with a problem trigger, you can filter by severity level. Selecting a severity level triggers the workflow for that level and all higher (more critical) levels.
Select Problem trigger to set Severity level for the trigger to alert on:
SEV-1SEV-2(SEV-2and higher)SEV-3(SEV-3and higher)SEV-4(SEV-4and higher)SEV-5(SEV-5and higher)
Setting the filter to Minor (3) triggers the workflow for Minor (3), Major (2), and Critical (1) problems, but not for Warning (4) or Informational (5) events.