- Resolving monitors from a no-data condition. This works for both simple and multi-alerts, but the value 0 must not cause the monitor to trigger. For example, this would not work for a monitor with the query `avg(last_10m):avg:system.cpu.idle{*} < 10` because this monitor triggers (instead of resolving) when it evaluates to 0. Avoid using this function for error rate monitors with `as_count()` queries. See the [as_count() in Monitor Evaluations guide][3] for more details.

- The `Monitor` summary type lists statuses and names of monitors matching the [monitor query][1]. Multi-alert monitors have only one row in the results list and their status is the multi-alert monitor’s overall status. The Status Counts are the number of matching monitors with each status type.

- The `Group` summary type lists statuses, names, and groups of monitors matching the monitor query. Multi-alert monitors are broken into several rows in the results list and correspond to each group and that group’s specific status in the multi-alert monitor. The `Group` summary type also supports `group` and `group_status` facets in its monitor query similar to the [Triggered Monitors][2] page. The Status Counts are the number of matching monitor groups with each status type.

- The `Combined` summary type lists the number of group statuses and names of the monitors matching the monitor query. Multi-alert monitors have only one row in the results list like in the `Monitor` summary type but the groups column displays the number of groups in each status type instead of the monitor’s overall status. Similar to the `Group` summary type, the `Combined` summary type also supports the `group` and `group_status` facets in its monitor query. The Status Counts still show the count of overall monitor statuses like in the `Monitor` summary type.

Events can include the following:

- Set up multi-alerts by device, host, and more

Datadog [Real User Monitoring][18] (RUM) allows you to visualize and analyze real-time user activities and experiences. With [Session Replay][19], you can capture and view the web browsing sessions of your users to better understand their behavior. In the RUM Explorer, you can not only visualize load times, frontend errors, and page dependencies, but also you can correlate business and application metrics to troubleshoot issues with application, infrastructure, and business metrics in one dashboard.

Datadog [Synthetic Monitoring][22] allow you to create and run API and browser tests that proactively simulate user transactions on your applications and monitor all internal and external network endpoints across your system's layers. You can detect errors, identify regressions, and automate rollbacks to prevent issues from surfacing in production.

After [assigning tags][1], start using them to filter and group your data in your Datadog platform. Tags can be used to include or exclude data.

To filter monitors by [assigned tags][1], use the search bar or facet checkboxes. The search bar format is `tag:<KEY>:<VALUE>`, for example: `tag:service:coffee-house`. To exclude monitors with a specific tag from your search, use `-`, for example: `tag:-service:coffee-house`.

* **avg by** text box to transform the monitor into a multi-alert monitor on each tag value.

The [RUM Explorer][15] visualizes events from your environment over a specified time period.

The [Synthetic Tests][1] page lists your Synthetic tests.

The [CI Results Explorer][1] displays your browser test results running in a [CI pipeline][2].

To filter SLOs by [assigned tags][1], use the search bar or facet checkboxes. The search bar format is `<KEY>:<VALUE>`, for example: `journey:add_item`. To exclude SLOs with a specific tag from your search, use `-`, for example: `-journey:add_item`.

Tags can be used in various ways with the [API][17].

title: multi-alert

A multi-alert applies the alert to each source according to the monitor's group parameter. An alert notification is sent for each group that meets the set conditions.

For more information, <a href="https://docs.datadoghq.com/monitors/create/configuration/?tab=thresholdalert#alert-grouping">see the documentation</a>.

Events generated when the daily quota is reached have the `datadog_index` tag by default, displaying the index name. You can optionally [create a facet][9] on the `datadog_index` tag, enabling its use in the `group by` step for [multi-alerts][10], as shown in the screenshot above.

Note that if your metric is only reporting by `host` with no `device` tag, it would not be detected by a monitor group by both `host` and `device`. [Tag Variables][2] are available for every group evaluated in the multi-alert to dynamically fill in notifications with useful context.

A monitor can be evaluated using cumulative time windows or rolling time windows. Cumulative time windows are best suited for questions that require historical context, such as "What's the sum of all the data available up to this point in time?" Rolling time windows are best suited for answering questions that do not require this context, such as "What's the average of the last _N_ data points?"

For a monitor that does not notify on missing data, the monitor skips evaluations and stays green until data returns that would change the status from OK.

**Note**: The group retention time option requires a multi-alert monitor that supports the [`On missing data`][5] option. These monitor types are APM Trace Analytics, Audit Logs, CI Pipelines, Error Tracking, Events, Logs, and RUM monitors.

The option is available with multi-alert mode.

<div class="alert alert-info"><strong>Note</strong>: There is a default limit of 1000 Trace Analytics monitors per account. If you are encountering this limit, consider using <a href="/monitors/create/configuration/?tab=thresholdalert#alert-grouping">multi-alerts</a>, or <a href="/help/">Contact Support</a>.</div>