[8.13] [DOCS] Clarify that all rules support alert summaries (#177755) (

#178577) # Backport This will backport the following commits from `main` to `8.13`: - [[DOCS] Clarify that all rules support alert summaries (#177755)](#177755)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport)  Co-authored-by: Lisa Cawley <[email protected]>
elastic · Mar 12, 2024 · 5e90da0 · 5e90da0
1 parent abdbf21
commit 5e90da0
Show file tree

Hide file tree

Showing 3 changed files with 15 additions and 22 deletions.
diff --git a/docs/management/maintenance-windows/maintenance-windows.asciidoc b/docs/management/maintenance-windows/maintenance-windows.asciidoc
@@ -54,11 +54,7 @@ If you turn on *Filter alerts*, you can use KQL to filter the alerts affected by
 image::images/create-maintenance-window-filter.png[The Create Maintenance Window user interface in {kib} with alert filters turned on]
 // NOTE: This is an autogenerated screenshot. Do not edit it directly.
 
-[NOTE]
-====
-* You can select only a single category when you turn on filters.
-* Some rules are not affected by maintenance window filters because their alerts do not contain requisite data. In particular, <<kibana-alerts,{stack-monitor-app}>>, <<geo-alerting,tracking containment>>, {ml-docs}/ml-configuring-alerts.html[{anomaly-jobs} health], and {ref}/transform-alerts.html[transform health] rules are not affected by the filters.
-====
+NOTE: You can select only a single category when you turn on filters.
 
 A maintenance window can have any one of the following statuses:
 

diff --git a/docs/user/alerting/alerting-getting-started.asciidoc b/docs/user/alerting/alerting-getting-started.asciidoc
@@ -75,7 +75,7 @@ When defining actions in a rule, you specify:
 
 Rather than repeatedly entering connection information and credentials for each action, {kib} simplifies action setup using <<action-types,connectors>>. For example if four rules send email notifications via the same SMTP service, they can all reference the same SMTP connector.
 
-The _action frequency_ defines when the action runs (for example, only when the alert status changes or at specific time intervals). Each rule type also has a set of the _action groups_ that affects when the action runs (for example, when the threshold is met or when the alert is recovered). If you want to reduce the number of notifications you receive without affecting their timeliness, some rule types support alert summaries. You can set the action frequency such that you receive notifications that summarize the new, ongoing, and recovered alerts at your preferred time intervals.
+The _action frequency_ defines when the action runs (for example, only when the alert status changes or at specific time intervals). Each rule type also has a set of the _action groups_ that affects when the action runs (for example, when the threshold is met or when the alert is recovered). If you want to reduce the number of notifications you receive without affecting their timeliness, set the action frequency to a summary of alerts. You will receive notifications that summarize the new, ongoing, and recovered alerts at your preferred time intervals.
 
 Some types of rules enable you to further refine the conditions under which actions run.
 For example, you can specify that actions run only when an alert occurs within a specific time frame or when it matches a KQL query.

diff --git a/docs/user/alerting/create-and-manage-rules.asciidoc b/docs/user/alerting/create-and-manage-rules.asciidoc
@@ -66,35 +66,32 @@ For details on what types of rules are available and how to configure them, refe
 [[defining-rules-actions-details]]
 ==== Actions
 
-You can add one or more actions to your rule to generate notifications when its
-conditions are met and when they are no longer met.
+You can add one or more actions to your rule to generate notifications when its conditions are met and when they are no longer met.
 
-Each action uses a connector, which provides connection information for a {kib} service or third party integration, depending on where you want to send the notifications. If no connectors exist, click **Add connector** to create one.
+Each action uses a connector, which provides connection information for a {kib} service or third party integration, depending on where you want to send the notifications.
+If no connectors exist, click **Add connector** to create one.
+
+After you select a connector, set the action frequency.
+You can choose to create a summary of alerts on each check interval or on a custom interval.
+Alternatively, you an choose to run actions for each alert (at each check interval, only when the alert status changes, or at a custom interval).
+
+NOTE: If you choose a custom action interval, it cannot be shorter than the rule's check interval.
 
-After you select a connector, set the action frequency. If the rule type supports alert summaries, you can choose to create a summary of alerts on each check interval or on a custom interval.
 For example, if you create an {es} query rule, you can send notifications that summarize the new, ongoing, and recovered alerts on a custom interval:
 
 [role="screenshot"]
 image::images/es-query-rule-action-summary.png[UI for defining alert summary action in an {es} query rule,500]
 // NOTE: This is an autogenerated screenshot. Do not edit it directly.
 
-[NOTE]
-====
-* Some rules that support alert summaries, such as metric threshold rules, enable you to further refine when actions run by adding time frame and query filters.
-* If you choose a custom action interval, it cannot be shorter than the rule's check interval.
-====
-
-Alternatively, you can set the action frequency such that the action runs for each alert.
-If the rule type does not support alert summaries, this is your only available option.
-You must choose when the action runs (for example, at each check interval, only when the alert status changes, or at a custom action interval).
-You must also choose an action group, which affects whether the action runs. Each rule type has a specific set of valid action groups.
+When you choose to run actions for each alert, you must specify an action group.
+Each rule type has a set of valid action groups, which affect when an action runs.
 For example, you can set *Run when* to `Query matched` or `Recovered` for the {es} query rule:
 
 [role="screenshot"]
 image::images/es-query-rule-recovery-action.png[UI for defining a recovery action,500]
 // NOTE: This is an autogenerated screenshot. Do not edit it directly.
 
-Each connector supports a specific set of actions for each action group and enables different action properties.
+Connectors have unique behavior for each action group.
 For example, you can have actions that create an {opsgenie} alert when rule conditions are met and recovery actions that close the {opsgenie} alert. For more information about connectors, refer to <<action-types>>.
 
 [[alerting-concepts-suppressing-duplicate-notifications]]
@@ -114,7 +111,7 @@ servers that continue to exceed the threshold:
 * Minute 2: X123 and Y456 > 0.9. _One email_ will be sent for Y456.
 * Minute 3: X123, Y456, Z789 > 0.9. _One email_ will be sent for Z789.
 
-To get notified only once when a server exceeds the threshold, you can set the action frequency to `On status changes`. Alternatively, if the rule type supports alert summaries, consider using them to reduce the volume of notifications.
+To get notified only once when a server exceeds the threshold, you can set the action frequency to `On status changes`. Alternatively, consider using alert summaries to reduce the volume of notifications.
 ==============================================
 
 [float]