diff --git a/docs/reference/transform/images/transform-alert-actions.png b/docs/reference/transform/images/transform-alert-actions.png
index ee3328ebd9907..a78c02fa305cd 100644
Binary files a/docs/reference/transform/images/transform-alert-actions.png and b/docs/reference/transform/images/transform-alert-actions.png differ
diff --git a/docs/reference/transform/transform-alerts.asciidoc b/docs/reference/transform/transform-alerts.asciidoc
index 5c3604bf6bc3e..334001d0064e6 100644
--- a/docs/reference/transform/transform-alerts.asciidoc
+++ b/docs/reference/transform/transform-alerts.asciidoc
@@ -1,8 +1,9 @@
-[role="xpack"]
 [[transform-alerts]]
 = Generating alerts for {transforms}
-
-beta::[]
+:frontmatter-description: Create {transform} health rules.
+:frontmatter-tags-products: [alerting]
+:frontmatter-tags-content-type: [how-to]
+:frontmatter-tags-user-goals: [configure]
 
 {kib} {alert-features} include support for {transform} rules, which check the 
 health of {ctransforms} with certain conditions. If the conditions of the rule 
@@ -17,7 +18,6 @@ The following {transform} rules are available:
 {transform-cap} health:: 
   Monitors {transforms} health and alerts if an operational issue occurred.
 
-
 [[creating-transform-rules]]
 == Creating a rule
 
@@ -53,29 +53,40 @@ image::images/transform-check-config.png["Selecting health check",500]
 
 As the last step in the rule creation process, define its actions.
   
-
 [[defining-actions]]
 == Defining 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.
+conditions are met and when they are no longer met. In particular, this rule
+type supports:
+
+* alert summaries
+* actions that run when an issue is detected
+* recovery actions that run when the rule 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
+For each action, you must choose a connector, which provides connection
+information for a {kib} service or third party integration. For more information
+about all the supported connectors, go to
 {kibana-ref}/action-types.html[Connectors].
 
-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).
+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:
 
 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 issue is detected
+or when it is recovered.
+
+You can further refine the conditions under which actions run by specifying that
+actions only run when they match a KQL query or when an alert occurs within a
+specific time frame.
+
 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.
@@ -92,3 +103,44 @@ The name of an alert is always the same as the {transform} ID of the associated
 {transform} that triggered it. You can mute the notifications for a particular 
 {transform} on the page of the rule that lists the individual alerts. You can 
 open it via *{rules-ui}* by selecting the rule name.
+
+[[transform-action-variables]]
+== Action variables
+
+The following variables are specific to the {transform} health rule type.
+You can also specify {kibana-ref}/rule-action-variables.html[variables common to all rules].
+
+`context.message`::
+A preconstructed message for the rule. For example: `Transform test-1 is not started.`
+
+`context.results`::
+The most recent results, which you can iterate over by using the 
+https://mustache.github.io/[Mustache] template array syntax. For example, the
+message in an email connector action might contain:
++
+--
+[source,sh]
+--------------------------------------------------
+[{{rule.name}}] Transform health check result:
+{{context.message}}
+{{#context.results}}
+  Transform ID: {{transform_id}}
+  {{#description}}Transform description: {{description}}
+  {{/description}}{{#transform_state}}Transform state: {{transform_state}}
+  {{/transform_state}}{{#health_status}}Transform health status: {{health_status}}
+  {{/health_status}}{{#issues}}Issue: {{issue}}
+  Issue count: {{count}}
+  {{#details}}Issue details: {{details}}
+  {{/details}}{{#first_occurrence}}First occurrence: {{first_occurrence}}
+  {{/first_occurrence}}
+  {{/issues}}{{#failure_reason}}Failure reason: {{failure_reason}}
+  {{/failure_reason}}{{#notification_message}}Notification message: {{notification_message}}
+  {{/notification_message}}{{#node_name}}Node name: {{node_name}}
+  {{/node_name}}{{#timestamp}}Timestamp: {{timestamp}}
+  {{/timestamp}}
+{{/context.results}}
+--------------------------------------------------
+--
+
+For more action variable examples, refer to
+{kibana-ref}/rule-action-variables.html[Rule action variables].
\ No newline at end of file