diff --git a/docs/detections/rules-ui-create.asciidoc b/docs/detections/rules-ui-create.asciidoc index fff8475118..7ae83b9162 100644 --- a/docs/detections/rules-ui-create.asciidoc +++ b/docs/detections/rules-ui-create.asciidoc @@ -48,6 +48,8 @@ NOTE: If a required job isn't currently running, it will automatically start whe + . preview:[] (Optional, https://www.elastic.co/pricing[Platinum or higher subscription] required) Use *Suppress alerts by* to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. + +NOTE: Because {ml} rules generate alerts from anomalies, alert documents don't contain source event fields and you can only use anomaly fields when configuring alert suppression. ++ //// The following step is repeated across all rule types. If you change anything diff --git a/docs/serverless/rules/rules-ui-create.mdx b/docs/serverless/rules/rules-ui-create.mdx index 4b4e8b154a..941c52c1cb 100644 --- a/docs/serverless/rules/rules-ui-create.mdx +++ b/docs/serverless/rules/rules-ui-create.mdx @@ -51,6 +51,10 @@ To create or edit ((ml)) rules, you need an appropriate user role. Additionally, 1. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to Suppress detection alerts for more information. + + Because ((ml)) rules generate alerts from anomalies, alert documents don't contain source event fields and you can only use anomaly fields when configuring alert suppression. + + {/* The following steps are repeated across multiple rule types. If you change anything in these steps or sub-steps, apply the change to the other rule types, too. */} 1. (Optional) Add **Related integrations** to associate the rule with one or more [Elastic integrations](((integrations-docs))). This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's installation status when viewing the rule. @@ -504,7 +508,7 @@ When writing your query, consider the following: - When writing an aggregating query, use the [`STATS...BY`](((ref))/esql-commands.html#esql-stats-by) command with fields that you want to search and filter for after alerts are created. For example, using the `host.name`, `user.name`, `process.name` fields with the `BY` operator of the `STATS...BY` command returns these fields in alert documents, and allows you to search and filter for them from the Alerts table. --- When configuring alert suppression on a non-aggregating query, we recommend sorting results by ascending `@timestamp` order. Doing so ensures that alerts are properly suppressed, especially if the number of alerts generated is higher than the **Max alerts per run** value. +- When configuring alert suppression on a non-aggregating query, we recommend sorting results by ascending `@timestamp` order. Doing so ensures that alerts are properly suppressed, especially if the number of alerts generated is higher than the **Max alerts per run** value.