[DOCS] Update anomaly detection jobs health rule details

docs/reference/ml/anomaly-detection/ml-configuring-alerts.asciidoc

@@ -5,8 +5,6 @@
 :frontmatter-tags-content-type: [how-to]
 :frontmatter-tags-user-goals: [configure]
 
-beta::[]
-
 {kib} {alert-features} include support for {ml} rules, which run scheduled 
 checks for anomalies in one or more {anomaly-jobs} or check the health of the 
 job with certain conditions. If the conditions of the rule are met, an alert is 
@@ -83,73 +81,7 @@ TIP: You must also provide a _check interval_ that defines how often to
 evaluate the rule conditions. It is recommended to select an interval that is
 close to the bucket span of the job.
 
-As the last step in the rule creation process, define its actions.
-
-[discrete]
-[[anomaly-alert-actions]]
-=== {anomaly-detect-cap} alert rule actions
-
-You can optionally send notifications when the rule conditions are met and when
-they are no longer met. In particular, this rule type supports:
-
-* alert summaries
-* actions that run when the anomaly score matches the conditions
-* recovery actions that run when the conditions are no longer met
-
-Each action uses a connector, which stores connection information for a {kib}
-service or supported third-party integration, depending on where you want to
-send the notifications. For example, you can use a Slack connector to send a
-message to a channel. Or you can use an index connector that writes an JSON
-object to a specific index. For details about creating connectors, refer to
-{kibana-ref}/action-types.html[Connectors].
-
-After you select a connector, you must set the action frequency. You can choose
-to create a summary of alerts on each check interval or on a custom interval.
-For example, send slack notifications that summarize the new, ongoing, and
-recovered alerts:
-
-[role="screenshot"]
-image::images/ml-anomaly-alert-action-summary.png["Adding an alert summary action to the rule",500]
-// NOTE: This is an autogenerated screenshot. Do not edit it directly.
-
-TIP: 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 actions run for each
-alert. Choose how often the action runs (at each check interval, only when the
-alert status changes, or at a custom action interval). You must also choose an
-action group, which indicates whether the action runs when the anomaly score is
-matched or when the alert is recovered. For example:
-
-[role="screenshot"]
-image::images/ml-anomaly-alert-action-score-matched.png["Adding an action for each alert in the rule",500]
-// NOTE: This is an autogenerated screenshot. Do not edit it directly.
-
-You can further refine the conditions under which actions run by specifying that
-actions only run they match a KQL query or when an alert occurs within a
-specific time frame.
-
-There is a set of variables that you can use to customize the notification
-messages for each action. Click the icon above the message text box to get the
-list of variables or refer to <<action-variables>>.
-
-[role="screenshot"]
-image::images/ml-anomaly-alert-messages.png["Customizing your message",500]
-// NOTE: This is an autogenerated screenshot. Do not edit it directly.
-
-After you save the configurations, the rule appears in the
-*{stack-manage-app} > {rules-ui}* list; you can check its status and see the
-overview of its configuration information.
-
-When an alert occurs, it is always the same name as the job ID of the associated 
-{anomaly-job} that triggered it. If necessary, you can snooze rules to prevent
-them from generating actions. For more details, refer to
-{kibana-ref}/create-and-manage-rules.html#controlling-rules[Snooze and disable rules].
-
-You can also review how the alerts that are occured correlate with the 
-{anomaly-detect} results in the **Anomaly exloprer** by using the 
-**Anomaly timeline** swimlane and the **Alerts** panel.
-
+As the last step in the rule creation process, define its <<ml-configuring-alert-actions,actions>>.
 
 [[creating-anomaly-jobs-health-rules]]
 == {anomaly-jobs-cap} health rules
@@ -197,36 +129,78 @@ close to the bucket span of the job.
 
 As the last step in the rule creation process, define its actions.
 
-[discrete]
-[[anomaly-jobs-health-actions]]
-=== {anomaly-jobs-cap} health rule actions
+[[ml-configuring-alert-actions]]
+== Actions
 
 You can optionally send notifications when the rule conditions are met and when
-they are no longer met. In particular, this rule type supports:
+they are no longer met. In particular, these rules support:
 
-* actions that run when an issue is detected
-* recovery actions that run when the rule conditions are no longer met
+* alert summaries
+* actions that run when the anomaly score matches the conditions (for {anomaly-detect} alert rules)
+* actions that run when an issue is detected (for {anomaly-jobs} health rules)
+* recovery actions that run when the conditions are no longer met
+
+Each action uses a connector, which stores connection information for a {kib}
+service or supported third-party integration, depending on where you want to
+send the notifications. For example, you can use a Slack connector to send a
+message to a channel. Or you can use an index connector that writes a JSON
+object to a specific index. For details about creating connectors, refer to
+{kibana-ref}/action-types.html[Connectors].
 
-For each action, you must choose a connector, which provides connection
-information for a {kib} service or third-party integration. You must set the
-action frequency, which involves choosing how often to run the action (for
-example, at each check interval, only when the alert status changes, or at a
-custom action interval). You must also choose one of the action groups (for
-example, the action runs when the issue is detected or when it is recovered).
+After you select a connector, you must set the action frequency. You can choose
+to create a summary of alerts on each check interval or on a custom interval.
+For example, send slack notifications that summarize the new, ongoing, and
+recovered alerts:
+
+[role="screenshot"]
+image::images/ml-anomaly-alert-action-summary.png["Adding an alert summary action to the rule",500]
+// NOTE: This is an autogenerated screenshot. Do not edit it directly.
+
+TIP: 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 actions run for each
+alert. Choose how often the action runs (at each check interval, only when the
+alert status changes, or at a custom action interval). For {anomaly-detect}
+alert rules, you must also choose whether the action runs when the anomaly score
+matches the condition or when the alert recovers:
+
+[role="screenshot"]
+image::images/ml-anomaly-alert-action-score-matched.png["Adding an action for each alert in the rule",500]
+// NOTE: This is an autogenerated screenshot. Do not edit it directly.
+
+In {anomaly-jobs} health rules, choose whether the action runs when the issue is
+detected or when it is recovered:
 
 [role="screenshot"]
 image::images/ml-health-check-action.png["Adding an action for each alert in the rule",500]
 // NOTE: This is an autogenerated screenshot. Do not edit it directly.
 
-You can pass rule values to an action to provide contextual details in the
-notification messages. For the list of variables that you can include in the
-message, click the icon above the message text box or refer to
-<<action-variables>>.
+You can further refine the rule by specifying that actions run only when they
+match a KQL query or when an alert occurs within a specific time frame.
+
+There is a set of variables that you can use to customize the notification
+messages for each action. Click the icon above the message text box to get the
+list of variables or refer to <<action-variables>>. For example:
+
+[role="screenshot"]
+image::images/ml-anomaly-alert-messages.png["Customizing your message",500]
+// NOTE: This is an autogenerated screenshot. Do not edit it directly.
 
 After you save the configurations, the rule appears in the
 *{stack-manage-app} > {rules-ui}* list; you can check its status and see the
 overview of its configuration information.
 
+When an alert occurs for an {anomaly-detect} alert rule, it is always the same
+name as the job ID of the associated {anomaly-job} that triggered it. You can
+review how the alerts that are occured correlate with the {anomaly-detect}
+results in the **Anomaly explorer** by using the **Anomaly timeline** swimlane
+and the **Alerts** panel.
+
+If necessary, you can snooze rules to prevent them from generating actions. For
+more details, refer to
+{kibana-ref}/create-and-manage-rules.html#controlling-rules[Snooze and disable rules].
+
 [[action-variables]]
 == Action variables