[DOCS] Refresh screenshots for machine learning rules (#93805)

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

@@ -36,16 +36,6 @@ In *{stack-manage-app} > {rules-ui}*, you can create both types of {ml} rules:
 image::images/ml-rule.png["Creating a new machine learning rule",500]
 // NOTE: This is an autogenerated screenshot. Do not edit it directly.
 
-When you create a {ml} rule, you must provide a time interval for the rule to
-check detected anomalies or job health changes. It is recommended to select an
-interval that is close to the bucket span of the job.
-
-You must also select a notification option, which affects how often alerts
-generate actions. Options include running actions at each check interval, only
-when the alert status changes, or at a custom action interval. For more
-information about these options, refer to the
-{kibana-ref}/create-and-manage-rules.html#defining-rules-general-details[General rule details].
-
 In the *{ml-app}* app, you can create only {anomaly-detect} alert rules; create
 them from the {anomaly-job} wizard after you start the job or from the
 {anomaly-job} list.
@@ -90,10 +80,11 @@ the sample results by providing a valid interval for your data. The generated
 preview contains the number of potentially created alerts during the relative 
 time range you defined.
 
-As the last step in the rule creation process, 
-<<defining-actions, define the actions>> that occur when the conditions
-are met.
+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, <<defining-actions,define its actions>>.
 
 [[creating-anomaly-jobs-health-rules]]
 === {anomaly-jobs-cap} health
@@ -135,24 +126,41 @@ _Errors in job messages_::
 image::images/ml-health-check-config.png["Selecting health checkers",500]
 // NOTE: This is an autogenerated screenshot. Do not edit it directly.
 
-As the last step in the rule creation process, 
-<<defining-actions, define the actions>> that occur when the conditions
-are met.
+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.
   
 
 [[defining-actions]]
 == Defining actions
 
-Your rule can use connectors, which are {kib} services or supported third-party
-integrations that run actions when the rule conditions are met or when the 
-alert is recovered. For details about creating connectors, refer to
+//tag::define-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.
+
+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].
 
-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.
-It's also possible to customize the notification messages. There is a set of
-variables that you can include in the message depending on the rule type; refer
-to <<action-variables>>.
+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). Each rule type also has a list of
+valid action groups and you must choose one of these groups (for example, the
+action runs when the issue is detected or when it is recovered).
+
+TIP: If you choose a custom action interval, it cannot be shorter than the
+rule's check interval.
+
+//end::define-actions[]
+
+It's also possible to customize the notification messages for each action. There
+is a set of variables that you can include in the message depending on the rule
+type; refer to <<action-variables>>.
 
 [role="screenshot"]
 image::images/ml-anomaly-alert-messages.png["Customizing your message",500]

docs/reference/transform/transform-alerts.asciidoc

@@ -27,7 +27,7 @@ On the *Create rule* window, give a name to the rule and optionally provide
 tags. Select the {transform} health rule type:
 
 [role="screenshot"]
-image::images/transform-rule.png["Creating a transform health rule"]
+image::images/transform-rule.png["Creating a transform health rule",500]
 // NOTE: This is screenshot is automatically generated. Do not edit it directly.
 
 [[creating-transform-health-rules]]
@@ -48,37 +48,23 @@ _Errors in {transform} messages_::
   Notifies if {transform} messages contain errors.
 
 [role="screenshot"]
-image::images/transform-check-config.png["Selecting health check"]
+image::images/transform-check-config.png["Selecting health check",500]
 // NOTE: This is screenshot is automatically generated. Do not edit it directly.
 
-As the last step in the rule creation process, define the actions that occur when the conditions are met.
+As the last step in the rule creation process, define its actions.
   
 
 [[defining-actions]]
 == Defining actions
 
-Connect your rule to actions that use supported built-in integrations by 
-selecting a connector type. Connectors are {kib} services or third-party 
-integrations that perform an action when the rule conditions are met or the 
-alert is recovered. You can select in which case the action will run. For
-example, you can choose a Slack connector and configure it to send a message to
-a specific channel. Alternatively, you can create an index connector that 
-writes the JSON object you configure to a specific index.
-
-After you select a connector, you must set the action frequency. Options include
-running actions at each check interval, only when the alert status changes, or
-at a custom action interval. For this particular type of rule, you can run
-actions when an issue is detected and when it is recovered. An alert remains
-active as long as the configured conditions are met during the check interval.
-When there is no matching condition in the next interval, the `Recovered` action
-group is invoked and the status of the alert changes to `OK`.
+include::{es-repo-dir}/ml/anomaly-detection/ml-configuring-alerts.asciidoc[tag=define-actions]
 
 It's also possible to customize the notification messages for each action. A
 list of variables is available to include in the message, like {transform} ID,
 description, {transform} state, and so on.
 
 [role="screenshot"]
-image::images/transform-alert-actions.png["Selecting connector type"]
+image::images/transform-alert-actions.png["Selecting connector type",500]
 // NOTE: This is screenshot is automatically generated. Do not edit it directly.
 
 After you save the configurations, the rule appears in the *{rules-ui}* list