on - edited on by
dawid_rampalski
- Confirm the event was actually generated
- Check if the issue was classified as a Frequent issue
- Check if the event was merged into an existing problem
- Check for an active Maintenance window
- Verify Anomaly detection thresholds and sensitivity
-
Check for problem suppression flags on the event
- What's next
Summary
This article provides a step-by-step checklist to help you investigate scenarios where a problem is expected to be raised in Dynatrace but is not appearing on the Problems page or triggering notifications. It covers the most common reasons including frequent issue detection, event merging, active maintenance windows, alerting profile scope, anomaly detection thresholds, and problem suppression and points you to the settings and tools you can use to validate each cause.
Problem
You expect Dynatrace to raise a problem for a specific issue; for example, a service failure, high CPU, or an unavailable process. But no problem appears on the Problems page, and no alert or notification is sent for the affected timeframe.
This can happen even when the underlying metric or event looks abnormal on the entity's chart. In most cases, the behavior is expected and caused by a configuration or Davis AI decision (such as frequent issue detection, event merging, an active maintenance window, anomaly detection thresholds, alerting profile scope, or problem suppression) rather than a monitoring gap.
Use the checklist below to identify which of these is responsible.
Troubleshooting steps
Confirm the event was actually generated
Problems are generated based on events. If there are no events, there is no problem. First, make sure that the event is present.
You can check the Events section of the entity page or query the data in a Notebook or Dashboard.
For example, filtering events for particular process instance:
fetch events
| filter dt.entity.process_group_instance == "PROCESS_GROUP_INSTANCE-F309E6AF540DAF55"
When no events are generated, verify the configuration of your anomaly detector, metric event, and problem generation settings. Make sure the data points match the sliding window configuration and confirm that anomaly detection is in a success state with the detector/metric event configurations enabled.
Check if the issue was classified as a Frequent issue
In the Events section of the entity page, filter for Frequent issue and adjust the timeframe to your investigation window. Compare the event timestamps against the time you expected the problem to appear.
Alternatively, use a Dashboard or Notebook and apply the same filters on event and entity. Check the property
dt.davis.is_frequent_issue_detection_allowed if the value is true,
the event is treated as a frequent issue, and no problem is generated.
You can confirm whether frequent issue detection is enabled by checking the event properties of the anomaly detector, as well as under Settings (Classic) → Anomaly detection → Frequent issue detection or within any other alerting configuration you have in place.
Check if the event was merged into an existing problem
If there's already an open problem, a new problem can be merged into it. This can happen either just before the new problem is created (as events are generated) or immediately after. When this occurs, the merged problem won't appear separately in the UI. Merging takes place when the events share the same root cause or occur around the same time with a topology match (vertical stack).
To confirm whether new events or problems were merged into an existing one, first check whether an open problem already exists. Then look for the property dt.davis.is_merging_allowed in the event properties; if its value is true, the new events have been merged into the existing open problem.
You can check if the merging is allowed in the event properties of anomaly detector and also any other alerting configuration you have.
Check for an active Maintenance window
Depending on the maintenance window configuration, alerts and notifications can be suppressed. To check whether an active maintenance window is being applied to the event, look for the maintenance.is_under_maintenance property. If its value is true, a maintenance window is applied to the event and depending on its configuration the alert or notification may be suppressed.
Note: Maintenance window is applied to the event timestamps not to the problem duration timestamps
Verify thresholds and sensitivity (Built-in anomaly detection):
For built-in anomaly detection (services, hosts, applications, and other Davis-detected anomalies), a problem is generated only when the monitored metric violates the configured threshold and the required sensitivity conditions are met.When investigating why a problem was not raised, verify that the threshold, sensitivity settings, and evaluation timeframe align with the observed behavior. If the metric did not satisfy the configured conditions for the required duration, no event will be generated and therefore no problem will be created.
Example:
For built-in service failure-rate detection, Dynatrace compares the current failure rate against the service's expected baseline. An event is generated only when all configured conditions are met:
For built-in anomaly detection (services, hosts, applications, and other Davis-detected anomalies), a problem is generated only when the monitored metric violates the configured threshold and the required sensitivity conditions are met.When investigating why a problem was not raised, verify that the threshold, sensitivity settings, and evaluation timeframe align with the observed behavior. If the metric did not satisfy the configured conditions for the required duration, no event will be generated and therefore no problem will be created.
Example:
For built-in service failure-rate detection, Dynatrace compares the current failure rate against the service's expected baseline. An event is generated only when all configured conditions are met:
- The current request volume meets the minimum requests per minute requirement.
- The abnormal condition persists for at least the configured duration.
- The failure rate exceeds both the configured absolute and relative thresholds.
Example scenario:
Assume the configuration is:
Assume the configuration is:
- Minimum requests per minute: 10
- Abnormal state duration: 1 minute
- Expected failure rate: 15%
- Absolute threshold: 0%
- Relative threshold: 50%
Dynatrace calculates:
- Absolute threshold = 15% + 0% = 15%
- Relative threshold = 15% + (15% × 50%) = 22.5%
Since both thresholds must be exceeded, the effective trigger point is 22.5%.If the failure rate rises to 25% but the service processes only 5 requests per minute, no event is generated because the minimum request volume condition is not met.Likewise, if the failure rate rises to 25% and the service processes 20 requests per minute, but the condition lasts only 30 seconds, no event is generated because the required duration has not been met.An event is generated only when the failure rate remains above 22.5%, the service receives at least 10 requests per minute, and the condition persists for at least 1 minute. Since problems are generated from events, if these conditions are not met, no failure-rate event and therefore no problem will be created.
Verify thresholds, evaluation window, and metric latency (Metric events and Davis anomaly detectors):
For metric events and custom Davis anomaly detectors, verify that the metric values satisfy the configured threshold and violating sample requirements within the selected sliding window timeframe.
To validate the behavior, you can query the metric in a Notebook with the same timeframe used by the alert configuration. If using the Notebook's Analyze and alert option, keep in mind that it may show a simulated alert result that does not always represent an actual generated event. For accurate validation, disable Analyze and alert, run the query using the same timeframe as the alert configuration, and verify whether the returned samples meet the configured alert conditions.
Additionally, consider metric ingestion latency. If metric data arrives later than expected, the anomaly detector may evaluate the sliding window before all relevant samples have been ingested. As a result, Dynatrace may not see enough violating samples during evaluation and no event will be generated.
ExampleAssume the following configuration:
For metric events and custom Davis anomaly detectors, verify that the metric values satisfy the configured threshold and violating sample requirements within the selected sliding window timeframe.
To validate the behavior, you can query the metric in a Notebook with the same timeframe used by the alert configuration. If using the Notebook's Analyze and alert option, keep in mind that it may show a simulated alert result that does not always represent an actual generated event. For accurate validation, disable Analyze and alert, run the query using the same timeframe as the alert configuration, and verify whether the returned samples meet the configured alert conditions.
Additionally, consider metric ingestion latency. If metric data arrives later than expected, the anomaly detector may evaluate the sliding window before all relevant samples have been ingested. As a result, Dynatrace may not see enough violating samples during evaluation and no event will be generated.
ExampleAssume the following configuration:
- Sliding window: 5 minutes
- Violating samples required: 3 of 5
- Threshold: CPU usage > 90%
- Metric ingestion latency: 2 minutes
The CPU exceeds 90% from 10:00 to 10:04, generating three violating samples. However, when Dynatrace evaluates the alert at 10:05, some of those samples have not yet been ingested because of the 2-minute delay. Since fewer than three violating samples are available during evaluation, the event is not created even though the chart later shows a threshold violation.
To address this, configure a Query offset that matches the observed ingestion latency. Query offset shifts the evaluation window backward in time, allowing Dynatrace to evaluate a complete set of ingested data rather than potentially incomplete real-time data. This helps prevent missed alerts caused solely by delayed metric ingestion.
You can find the steps to check metric latency in this article, under the Query your data section.
How to set up Metric events / Davis anomaly detectors - Community HomeCheck for problem suppression flags on the event
A problem is suppressed when the event carries
First, through an explicit setting on event ingest, where you or the source integration set
Second, by manually closing a problem, which can cause Davis to apply the same property to the underlying custom event and block future problems. To raise a new problem, the suppressed event must be resolved, after which a newly reported event will open a fresh problem.
dt.davis.is_problem_suppressed=true. This can happen in two ways. First, through an explicit setting on event ingest, where you or the source integration set
dt.davis.is_problem_suppressed=true as an event property on a custom event, and Davis skips problem creation. Second, by manually closing a problem, which can cause Davis to apply the same property to the underlying custom event and block future problems. To raise a new problem, the suppressed event must be resolved, after which a newly reported event will open a fresh problem.
Additional note:
Problem creation depends on its configuration. So, if it was working fine previously and is not working now, check the revision history of the related configurations (anomaly detector, metric event, tags, management zone, segments) to see whether any recent changes were made which might affect the alerting.
What's next
If you've worked through the full checklist and the cause is still unclear, please open a support case and include the configuration link used for alerting, the affected entity, and the expected problem timestamp (with time zone). It also helps to include screenshots of the anomaly, the event properties you checked, and any recent configuration changes along with their revision history.
