[Alerting] Update UI to reflect new terminology (#93597)

* Renaming alerts to rules

* Updating formatted messages

* Updating i18n labels

* Completed renaming in UI

* Updating client routes including redirect

* wip docs update

* Reverting title changes for now

* Fixing types check

* Fixing unit tests

* Fixing functional test

* Fixing functional test

* docs wip

* wip docs update

* Finished first run through docs

* docs docs docs

* Fixing bad merge

* Fixing functional test

* Docs cleanup

* Cleaning up i18n labels

* Fixing functional test

* Updating screenshots

* Updating screenshots

* Updating screenshots

* Updating terminology in alerting examples

* Updating terminology in alerting examples

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

docs/action-type-template.asciidoc

@@ -1,10 +1,10 @@
 [[<ACTION-TYPE>-action-type]]
-=== <ACTION-TYPE> action
+=== <ACTION-TYPE> connector and action
 ++++
 <titleabbrev><ACTION-TYPE></titleabbrev>
 ++++
 
-Include a short description of the action type.
+Include a short description of the connector type.
 
 [float]
 [[<ACTION-TYPE>-connector-configuration]]
@@ -13,7 +13,7 @@ Include a short description of the action type.
 <ACTION-TYPE> connectors have the following configuration properties.
 
 ////
-List of user-facing connector configurations. This should align with the fields available in the Create connector flyout form for this action type.
+List of user-facing connector configurations. This should align with the fields available in the Create connector flyout form for this connector type.
 ////
 
 Property1:: A short description of this property.
@@ -21,16 +21,16 @@ Property2:: A short description of this property with format hints. This can be
 
 [float]
 [[Preconfigured-<ACTION-TYPE>-configuration]]
-==== Preconfigured action type
+==== Preconfigured connector type
 
 ////
-Example preconfigured format for this action type
+Example preconfigured format for this connector type
 ////
 
 [source,text]
 --
  my-<ACTION-TYPE>:
-   name: preconfigured-<ACTION-TYPE>-action-type
+   name: preconfigured-<ACTION-TYPE>-connector-type
    actionTypeId: .<ACTION-TYPE>
    config:
      property1: value1
@@ -39,17 +39,15 @@ Example preconfigured format for this action type
      property3: value3
 --
 
-[float]
-[[<ACTION-TYPE>-connector-config-properties]]
 ////
 List of properties from the ConfigSchema and SecretsSchema for this action type.
 ////
-Config defines information for the action type.
+Config defines information for the connector type.
 
 `property1`:: A short description of this property.
 `property2`:: A short descriptionn of this property.
 
-Secrets defines sensitive information for the action type.
+Secrets defines sensitive information for the connector type.
 
 `property3`:: A short descriptionn of this property.
 
@@ -57,7 +55,7 @@ Secrets defines sensitive information for the action type.
 [[<ACTION-TYPE>-action-configuration]]
 ==== Action configuration
 
-<ACTION-TYPE> actions have the following configuration properties.
+<ACTION-TYPE> actions have the following properties.
 
 ////
 List of user-facing action configurations. This should align with the fields available in the Action section of the Create/Update alert flyout.

docs/alert-type-template.asciidoc

@@ -1,39 +0,0 @@
-[[alert-type-<ALERT TYPE>]]
-=== <ALERT TYPE>
-
-Include a short description of the alert type.
-
-[float]
-==== Create the alert
-
-Fill in the <<defining-alerts-general-details, alert details>>, then select *<ALERT TYPE>*.
-
-[float]
-==== Define the conditions
-
-Define properties to detect the condition.
-
-////
-Optional, include a screenshot
-[role="screenshot"]
-image::user/alerting/images/alert-types-<ALERT TYPE>-conditions.png[Conditions for <ALERT TYPE> alert type]
-////
-
-Condition1:: This is a condition the user must define.
-Condition2:: This is another condition the user must define.
-
-[float]
-==== Add action variables
-
-<<defining-alerts-actions-details, Add an action>> to run when the alert condition is met. The following variables are specific to the <ALERT TYPE> alert. You can also specify <<defining-alerts-actions-variables, variables common to all alerts>>.
-
-`context.variableA`:: A short description of the context variable defined by the alert type.
-`context.variableB`:: A short description of the context variable defined by the alert type with an example. Example: `this is what variableB outputs`.
-
-////
-Optional, include a step-by-step example for creating this alert 
-[float]
-==== Example
-
-In this section, you will use the {kib} <<add-sample-data, weblog sample dataset>> to setup and tune the conditions on an <ALERT TYPE> alert. For this example, we want to detect when <DESCRIBE THE CONDITIONS>.
-////

docs/management/alerting/alert-details.asciidoc

@@ -1,33 +0,0 @@
-[role="xpack"]
-[[alert-details]]
-=== Alert details
-
-
-The *Alert details* page tells you about the state of the alert and provides granular control over the actions it is taking. 
-
-[role="screenshot"]
-image::images/alerts-details-instances-active.png[Alert details page with three alert instances]
-
-In this example, alerts detect when a site serves more than a threshold number of bytes in a 24 hour period. Three sites are above the threshold. These are called alert instances - occurrences of the condition being detected - and the instance name, status, time of detection, and duration of the condition are shown in this view. 
-
-Upon detection, each instance can trigger one or more actions. If the condition persists, the same actions will trigger either on the next scheduled alert check, or (if defined) after the re-notify period on the alert has passed. To prevent re-notification, you can suppress future actions by clicking on the eye icon to mute an individual alert instance. Muting means that the alert checks continue to run on a schedule, but that instance will not trigger any action.
-
-[role="screenshot"]
-image::images/alerts-details-instance-muting.png[Muting an alert instance]
-
-Alert instances will come and go from the list depending on whether they meet the alert conditions or not - unless they are muted. If a muted instance no longer meets the alert conditions, it will appear as inactive in the list. This prevents an instance from triggering actions if it reappears in the future. 
-
-[role="screenshot"]
-image::images/alerts-details-instances-inactive.png[Alert details page with three inactive alert instances]
-
-If you want to suppress actions on all current and future instances, you can mute the entire alert. Alert checks continue to run and the instance list will update as instances activate or deactivate, but no actions will be triggered.
-
-[role="screenshot"]
-image::images/alerts-details-muting.png[Use the mute toggle to suppress all action on current and future instances]
-
-You can also disable an alert altogether. When disabled, the alert stops running checks altogether and will clear any instances it is tracking. You may want to disable alerts that are not currently needed to reduce the load on {kib} and {es}.
-
-[role="screenshot"]
-image::images/alerts-details-disabling.png[Use the disable toggle to turn off alert checks and clear instances tracked]
-
-* For further information on alerting concepts and examples, see <<alerting-getting-started>>.

docs/management/alerting/alert-management.asciidoc

@@ -1,58 +0,0 @@
-[role="xpack"]
-[[alert-management]]
-=== Managing Alerts
-
-
-The *Alerts* tab provides a cross-app view of alerting. Different {kib} apps like {observability-guide}/create-alerts.html[*Observability*], {security-guide}/prebuilt-rules.html[*Security*], <<geo-alerting, *Maps*>> and <<xpack-ml, *Machine Learning*>> can offer their own alerts. The *Alerts* tab provides a central place to:
-
-* <<create-edit-alerts, Create and edit>> alerts
-* <<controlling-alerts, Control alerts>> including enabling/disabling, muting/unmuting, and deleting
-* Drill-down to <<alert-details, alert details>>
-
-[role="screenshot"]
-image:management/alerting/images/alerts-and-actions-ui.png[Example alert listing in the Alerts and Actions UI]
-
-For more information on alerting concepts and the types of alerts and actions available, see <<alerting-getting-started>>.
-
-[float]
-==== Finding alerts
-
-The *Alerts* tab lists all alerts in the current space, including summary information about their execution frequency, tags, and type.
-
-The *search bar* can be used to quickly find alerts by name or tag.
-
-[role="screenshot"]
-image::images/alerts-filter-by-search.png[Filtering the alerts list using the search bar]
-
-The *type* dropdown lets you filter to a subset of alert types.
-
-[role="screenshot"]
-image::images/alerts-filter-by-type.png[Filtering the alerts list by types of alert]
-
-The *Action type* dropdown lets you filter by the type of action used in the alert.
-
-[role="screenshot"]
-image::images/alerts-filter-by-action-type.png[Filtering the alert list by type of action]
-
-[float]
-[[create-edit-alerts]]
-==== Creating and editing alerts
-
-Many alerts must be created within the context of a {kib} app like <<metrics-app, Metrics>>, <<xpack-apm, APM>>, or <<uptime-app, Uptime>>, but others are generic. Generic alert types can be created in the *Alerts* management UI by clicking the *Create* button. This will launch a flyout that guides you through selecting an alert type and configuring it's properties. Refer to <<alert-types>> for details on what types of alerts are available and how to configure them.
-
-After an alert is created, you can re-open the flyout and change an alerts properties by clicking the *Edit* button shown on each row of the alert listing.
-
-
-[float]
-[[controlling-alerts]]
-==== Controlling alerts
-
-The alert listing allows you to quickly mute/unmute, disable/enable, and delete individual alerts by clicking the action button. 
-
-[role="screenshot"]
-image:management/alerting/images/individual-mute-disable.png[The actions button allows an individual alert to be muted, disabled, or deleted]
-
-These operations can also be performed in bulk by multi-selecting alerts and clicking the *Manage alerts* button:
-
-[role="screenshot"]
-image:management/alerting/images/bulk-mute-disable.png[The Manage alerts button lets you mute/unmute, enable/disable, and delete in bulk]

docs/management/alerting/alerts-and-actions-intro.asciidoc

@@ -1,30 +0,0 @@
-[role="xpack"]
-[[managing-alerts-and-actions]]
-== Alerts and Actions
-
-
-The *Alerts and Actions* UI lets you <<alert-management, see and control all the alerts>> in a space, and provides tools to <<connector-management, create and manage connectors>> so that alerts can trigger actions like notification, indexing, and ticketing.
-
-To manage alerting and connectors, open the main menu,
-then click *Stack Management > Alerts and Insights > Alerts and Actions*.
-
-[role="screenshot"]
-image:management/alerting/images/alerts-and-actions-ui.png[Example alert listing in the Alerts and Actions UI]
-
-[NOTE]
-============================================================================
-Similar to dashboards, alerts and connectors reside in a <<xpack-spaces, space>>.
-The *Alerts and Actions* UI only shows alerts and connectors for the current space.
-============================================================================
-
-[NOTE]
-============================================================================
-{es} also offers alerting capabilities through Watcher, which
-can be managed through the <<watcher-ui, Watcher UI>>. See
-<<alerting-concepts-differences>> for more information.
-============================================================================
-
-[float]
-=== Required permissions
-
-Access to alerts and actions is granted based on your privileges to alerting-enabled features. See <<alerting-security, Alerting Security>> for more information.

docs/management/alerting/connector-management.asciidoc

@@ -2,14 +2,12 @@
 [[connector-management]]
 === Managing Connectors
 
-beta[]
-
-Alerts use *Connectors* to route actions to different destinations like log files, ticketing systems, and messaging tools. While each {kib} app can offer their own types of alerts, they typically share connectors. The *Connectors* tab offers a central place to view and manage all the connectors in the current space.
+Rules use *Connectors* to route actions to different destinations like log files, ticketing systems, and messaging tools. While each {kib} app can offer their own types of rules, they typically share connectors. The *Connectors* tab offers a central place to view and manage all the connectors in the current space.
 
 For more information on connectors and the types of actions available see <<action-types>>.
 
 [role="screenshot"]
-image::images/connector-listing.png[Example connector listing in the Alerts and Actions UI]
+image::images/connector-listing.png[Example connector listing in the Rules and Connectors UI]
 
 
 [float]
@@ -21,15 +19,10 @@ The *Connectors* tab lists all connectors in the current space. The *search bar*
 image::images/connector-filter-by-search.png[Filtering the connector list using the search bar]
 
 
-The *type* dropdown also lets you filter to a subset of action types.
+The *type* dropdown also lets you filter to a subset of connector types.
 
 [role="screenshot"]
-image::images/connector-filter-by-type.png[Filtering the connector list by types of actions]
-
-The *Actions* column indicates the number of actions that reference the connector. This count helps you confirm a connector is unused before you delete it, and tells you how many actions will be affected when a connector is modified.
-
-[role="screenshot"]
-image::images/connector-action-count.png[Filtering the connector list by types of actions]
+image::images/connector-filter-by-type.png[Filtering the connector list by types of connectors]
 
 You can delete individual connectors using the trash icon. Connectors can also be deleted in bulk by multi-selecting them and clicking the *Delete* button to the left of the search box. 
 
@@ -44,4 +37,4 @@ When this happens the action will fail to execute, and appear as errors in the {
 
 ==== Creating a new connector
 
-New connectors can be created by clicking the *Create connector* button, which will guide you to select the type of connector and configure it's properties. Refer to <<action-types>> for the types of connectors available and how to configure them. Once you create a connector it will be made available to you anytime you set up an action in the current space.
+New connectors can be created by clicking the *Create connector* button, which will guide you to select the type of connector and configure its properties. Refer to <<action-types>> for the types of connectors available and how to configure them. Once you create a connector it will be made available to you anytime you set up an action in the current space.

docs/management/alerting/rule-details.asciidoc

@@ -0,0 +1,33 @@
+[role="xpack"]
+[[rule-details]]
+=== Rule details
+
+
+The *Rule details* page tells you about the state of the rule and provides granular control over the actions it is taking. 
+
+[role="screenshot"]
+image::images/rule-details-alerts-active.png[Rule details page with three alerts]
+
+In this example, the rule detects when a site serves more than a threshold number of bytes in a 24 hour period. Three sites are above the threshold. These are called alerts - occurrences of the condition being detected - and the alert name, status, time of detection, and duration of the condition are shown in this view.
+
+Upon detection, each alert can trigger one or more actions. If the condition persists, the same actions will trigger either on the next scheduled rule check, or (if defined) after the re-notify period on the rule has passed. To prevent re-notification, you can suppress future actions by clicking on the eye icon to mute an individual alert. Muting means that the rule checks continue to run on a schedule, but that alert will not trigger any action.
+
+[role="screenshot"]
+image::images/rule-details-alert-muting.png[Muting an alert]
+
+Alerts will come and go from the list depending on whether they meet the rule conditions or not - unless they are muted. If a muted instance no longer meets the rule conditions, it will appear as inactive in the list. This prevents an alert from triggering actions if it reappears in the future.
+
+[role="screenshot"]
+image::images/rule-details-alerts-inactive.png[Rule details page with three inactive alerts]
+
+If you want to suppress actions on all current and future alerts, you can mute the entire rule. Rule checks continue to run and the alert list will update as alerts activate or deactivate, but no actions will be triggered.
+
+[role="screenshot"]
+image::images/rule-details-muting.png[Use the mute toggle to suppress all actions on current and future alerts]
+
+You can also disable a rule altogether. When disabled, the rule stops running checks altogether and will clear any alerts it is tracking. You may want to disable rules that are not currently needed to reduce the load on {kib} and {es}.
+
+[role="screenshot"]
+image::images/rule-details-disabling.png[Use the disable toggle to turn off rule checks and clear alerts tracked]
+
+* For further information on alerting concepts and examples, see <<alerting-getting-started>>.

docs/management/alerting/rule-management.asciidoc

@@ -0,0 +1,58 @@
+[role="xpack"]
+[[alert-management]]
+=== Managing Rules
+
+
+The *Rules* tab provides a cross-app view of alerting. Different {kib} apps like {observability-guide}/create-alerts.html[*Observability*], {security-guide}/prebuilt-rules.html[*Security*], <<geo-alerting, *Maps*>> and <<xpack-ml, *Machine Learning*>> can offer their own rules. The *Rules* tab provides a central place to:
+
+* <<create-edit-rules, Create and edit>> rules
+* <<controlling-rules, Control rules>> including enabling/disabling, muting/unmuting, and deleting
+* Drill-down to <<rule-details, rule details>>
+
+[role="screenshot"]
+image:management/alerting/images/rules-and-connectors-ui.png[Example rule listing in the Rules and Connectors UI]
+
+For more information on alerting concepts and the types of rules and connectors available, see <<alerting-getting-started>>.
+
+[float]
+==== Finding rules
+
+The *Rules* tab lists all rules in the current space, including summary information about their execution frequency, tags, and type.
+
+The *search bar* can be used to quickly find rules by name or tag.
+
+[role="screenshot"]
+image::images/rules-filter-by-search.png[Filtering the rules list using the search bar]
+
+The *type* dropdown lets you filter to a subset of rule types.
+
+[role="screenshot"]
+image::images/rules-filter-by-type.png[Filtering the rules list by types of rule]
+
+The *Action type* dropdown lets you filter by the type of action used in the rule.
+
+[role="screenshot"]
+image::images/rules-filter-by-action-type.png[Filtering the rule list by type of action]
+
+[float]
+[[create-edit-rules]]
+==== Creating and editing rules
+
+Many rules must be created within the context of a {kib} app like <<metrics-app, Metrics>>, <<xpack-apm, APM>>, or <<uptime-app, Uptime>>, but others are generic. Generic rule types can be created in the *Rules* management UI by clicking the *Create* button. This will launch a flyout that guides you through selecting a rule type and configuring its properties. Refer to <<rule-types>> for details on what types of rules are available and how to configure them.
+
+After a rule is created, you can re-open the flyout and change a rule's properties by clicking the *Edit* button shown on each row of the rule listing.
+
+
+[float]
+[[controlling-rules]]
+==== Controlling rules
+
+The rule listing allows you to quickly mute/unmute, disable/enable, and delete individual rules by clicking the action button. 
+
+[role="screenshot"]
+image:management/alerting/images/individual-mute-disable.png[The actions button allows an individual rule to be muted, disabled, or deleted]
+
+These operations can also be performed in bulk by multi-selecting rules and clicking the *Manage rules* button:
+
+[role="screenshot"]
+image:management/alerting/images/bulk-mute-disable.png[The Manage rules button lets you mute/unmute, enable/disable, and delete in bulk]

docs/management/alerting/rules-and-connectors-intro.asciidoc

@@ -0,0 +1,29 @@
+[role="xpack"]
+[[managing-alerts-and-actions]]
+== Rules and Connectors
+
+
+The *Rules and Connectors* UI lets you <<alert-management, see and control all the rules>> in a space, and provides tools to <<connector-management, create and manage connectors>> so that rules can trigger actions like notification, indexing, and ticketing.
+
+To manage rules and connectors, open the main menu, then click *Stack Management > Alerts and Insights > Rules and Connectors*.
+
+[role="screenshot"]
+image:management/alerting/images/rules-and-connectors-ui.png[Example rule listing in the Rules and Connectors UI]
+
+[NOTE]
+============================================================================
+Similar to dashboards, rules and connectors reside in a <<xpack-spaces, space>>.
+The *Rules and Connectors* UI only shows rules and connectors for the current space.
+============================================================================
+
+[NOTE]
+============================================================================
+{es} also offers alerting capabilities through Watcher, which
+can be managed through the <<watcher-ui, Watcher UI>>. See
+<<alerting-concepts-differences>> for more information.
+============================================================================
+
+[float]
+=== Required permissions
+
+Access to rules and connectors is granted based on your privileges to alerting-enabled features. See <<alerting-security, Alerting Security>> for more information.

docs/rule-type-template.asciidoc

@@ -0,0 +1,39 @@
+[[rule-type-<RULE TYPE>]]
+=== <RULE TYPE>
+
+Include a short description of the rule type.
+
+[float]
+==== Create the rule
+
+Fill in the <<defining-alerts-general-details, rule details>>, then select *<RULE TYPE>*.
+
+[float]
+==== Define the conditions
+
+Define properties to detect the condition.
+
+////
+Optional, include a screenshot
+[role="screenshot"]
+image::user/alerting/images/rule-types-<RULE TYPE>-conditions.png[Conditions for <RULE TYPE> rule type]
+////
+
+Condition1:: This is a condition the user must define.
+Condition2:: This is another condition the user must define.
+
+[float]
+==== Add action variables
+
+<<defining-alerts-actions-details, Add an action>> to run when the rule condition is met. The following variables are specific to the <RULE TYPE> rule. You can also specify <<defining-alerts-actions-variables, variables common to all rules>>.
+
+`context.variableA`:: A short description of the context variable defined by the rule type.
+`context.variableB`:: A short description of the context variable defined by the rule type with an example. Example: `this is what variableB outputs`.
+
+////
+Optional, include a step-by-step example for creating this rule 
+[float]
+==== Example
+
+In this section, you will use the {kib} <<add-sample-data, weblog sample dataset>> to setup and tune the conditions on an <RULE TYPE> rule. For this example, we want to detect when <DESCRIBE THE CONDITIONS>.
+////

docs/settings/alert-action-settings.asciidoc

@@ -23,14 +23,14 @@ You can configure the following settings in the `kibana.yml` file.
 
 | `xpack.encryptedSavedObjects`
 `.encryptionKey`
-  | A string of 32 or more characters used to encrypt sensitive properties on alerts and actions before they're stored in {es}. Third party credentials — such as the username and password used to connect to an SMTP service — are an example of encrypted properties. +
+  | A string of 32 or more characters used to encrypt sensitive properties on alerting rules and actions before they're stored in {es}. Third party credentials — such as the username and password used to connect to an SMTP service — are an example of encrypted properties. +
   +
   {kib} offers a <<kibana-encryption-keys, CLI tool>> to help generate this encryption key. +
   +
-  If not set, {kib} will generate a random key on startup, but all alert and action functions will be blocked. Generated keys are not allowed for alerts and actions because when a new key is generated on restart, existing encrypted data becomes inaccessible. For the same reason, alerts and actions in high-availability deployments of {kib} will behave unexpectedly if the key isn't the same on all instances of {kib}. +
+  If not set, {kib} will generate a random key on startup, but all alerting and action functions will be blocked. Generated keys are not allowed for alerting and actions because when a new key is generated on restart, existing encrypted data becomes inaccessible. For the same reason, alerting and actions in high-availability deployments of {kib} will behave unexpectedly if the key isn't the same on all instances of {kib}. +
   +
   Although the key can be specified in clear text in `kibana.yml`, it's recommended to store this key securely in the <<secure-settings,{kib} Keystore>>.
-  Be sure to back up the encryption key value somewhere safe, as your alerts and actions will cease to function due to decryption failures should you lose it.  If you want to rotate the encryption key, be sure to follow the instructions on <<encryption-key-rotation, encryption key rotation>>.
+  Be sure to back up the encryption key value somewhere safe, as your alerting rules and actions will cease to function due to decryption failures should you lose it.  If you want to rotate the encryption key, be sure to follow the instructions on <<encryption-key-rotation, encryption key rotation>>.
 
 |===
 
@@ -75,6 +75,6 @@ a|`xpack.actions.`
 
 [float]
 [[alert-settings]]
-==== Alert settings
+==== Alerting settings
 
 You do not need to configure any additional settings to use alerting in {kib}.

docs/user/alerting/action-types.asciidoc

@@ -1,8 +1,8 @@
 [role="xpack"]
 [[action-types]]
-== Actions and connectors
+== Connectors and actions
 
-Actions are Kibana services or integrations with third-party systems that run as background tasks on the Kibana server when alert conditions are met. {kib} provides the following types of actions:
+Connectors provide a central place to store connection information for services and integrations with third party systems. Actions are instantiations of a connector that are linked to rules and run as background tasks on the {kib} server when rule conditions are met. {kib} provides the following types of connectors:
 
 [cols="2"]
 |===
@@ -50,20 +50,18 @@ a| <<webhook-action-type, Webhook>>
 
 [NOTE]
 ==============================================
-Some action types are paid commercial features, while others are free.
+Some connector types are paid commercial features, while others are free.
 For a comparison of the Elastic subscription levels,
 see https://www.elastic.co/subscriptions[the subscription page].
 ==============================================
 
 [float]
 [[create-connectors]]
-=== Preconfigured actions and connectors
+=== Preconfigured connectors
 
-For out-of-the-box and standardized connectors, you can <<preconfigured-connector-example, preconfigure the connector>>
+For out-of-the-box and standardized connectors, you can <<preconfigured-connector-example, preconfigure connectors>>
 before {kib} starts.
 
-If you preconfigure a connector, you can also <<preconfigured-action-type-example, preconfigure its action type>>.
-
 include::action-types/email.asciidoc[]
 include::action-types/resilient.asciidoc[]
 include::action-types/index.asciidoc[]

docs/user/alerting/action-types/email.asciidoc

@@ -1,11 +1,11 @@
 [role="xpack"]
 [[email-action-type]]
-=== Email action
+=== Email connector and action
 ++++
 <titleabbrev>Email</titleabbrev>
 ++++
 
-The email action type uses the SMTP protocol to send mail message, using an integration of https://nodemailer.com/[Nodemailer]. Email message text is sent as both plain text and html text.
+The email connector uses the SMTP protocol to send mail messages, using an integration of https://nodemailer.com/[Nodemailer]. Email message text is sent as both plain text and html text.
 
 NOTE: For emails to have a footer with a link back to {kib}, set the <<server-publicBaseUrl, `server.publicBaseUrl`>> configuration setting.
 
@@ -26,12 +26,12 @@ Password::  Password for login type authentication.
 
 [float]
 [[Preconfigured-email-configuration]]
-==== Preconfigured action type
+==== Preconfigured connector type
 
 [source,text]
 --
  my-email:
-   name: preconfigured-email-action-type
+   name: preconfigured-email-connector-type
    actionTypeId: .email
    config:
      from: testsender@test.com
@@ -43,7 +43,7 @@ Password::  Password for login type authentication.
      password: passwordkeystorevalue
 --
 
-Config defines information for the action type.
+Config defines information for the connector type.
 
 `service`:: The name of a https://nodemailer.com/smtp/well-known/[well-known email service provider]. If `service` is provided, `host`, `port`, and `secure` properties are ignored. For more information on the `gmail` service value, see the https://nodemailer.com/usage/using-gmail/[Nodemailer Gmail documentation].
 `from`:: An email address that corresponds to *Sender*.
@@ -52,7 +52,7 @@ Config defines information for the action type.
 `secure`:: A boolean that corresponds to *Secure*.
 `hasAuth`:: A boolean that corresponds to *Requires authentication*. If `true`, this connector will require values for `user` and `password` inside the secrets configuration. Defaults to `true`.
 
-Secrets defines sensitive information for the action type.
+Secrets defines sensitive information for the connector type.
 
 `user`:: A string that corresponds to *Username*. Required if `hasAuth` is set to `true`.
 `password`:: A string that corresponds to *Password*. Should be stored in the <<creating-keystore, {kib} keystore>>. Required if `hasAuth` is set to `true`.
@@ -71,24 +71,22 @@ Message::       The message text of the email. Markdown format is supported.
 [[configuring-email]]
 ==== Configuring email accounts for well-known services
 
-The email action can send email using many popular SMTP email services.
+The email connector can send email using many popular SMTP email services.
 
-You configure the email action to send emails using the connector form.
-For more information about configuring the email connector to work with different email
-systems, refer to:
+For more information about configuring the email connector to work with different email systems, refer to:
 
 * <<gmail>>
 * <<outlook>>
 * <<exchange>>
 * <<amazon-ses>>
 
-For other email servers, you can check the list of well-known services that Nodemailer supports in the JSON file https://github.com/nodemailer/nodemailer/blob/master/lib/well-known/services.json[well-known/services.json].  The properties of the objects in those files &mdash; `host`, `port`, and `secure` &mdash; correspond to the same email action configuration properties.  A missing `secure` property in the "well-known/services.json" file is considered `false`.  Typically, `port: 465` uses `secure: true`, and `port: 25` and `port: 587` use `secure: false`.
+For other email servers, you can check the list of well-known services that Nodemailer supports in the JSON file https://github.com/nodemailer/nodemailer/blob/master/lib/well-known/services.json[well-known/services.json].  The properties of the objects in those files &mdash; `host`, `port`, and `secure` &mdash; correspond to the same email connector configuration properties.  A missing `secure` property in the "well-known/services.json" file is considered `false`.  Typically, `port: 465` uses `secure: true`, and `port: 25` and `port: 587` use `secure: false`.
 
 [float]
 [[gmail]]
 ===== Sending email from Gmail
 
-Use the following email account settings to send email from the
+Use the following email connector configuration to send email from the
 https://mail.google.com[Gmail] SMTP service:
 
 [source,text]
@@ -108,7 +106,7 @@ to configure Gmail to https://support.google.com/accounts/answer/6010255?hl=en[a
 less secure apps to access your account].
 
 If two-step verification is enabled for your account, you must generate and use
-a unique App Password to send email from {watcher}. See
+a unique App Password to send email from {kib}. See
 https://support.google.com/accounts/answer/185833?hl=en[Sign in using App Passwords]
 for more information.
 
@@ -116,7 +114,7 @@ for more information.
 [[outlook]]
 ===== Sending email from Outlook.com
 
-Use the following email account settings to send email action from the
+Use the following email connector configuration to send email from the
 https://www.outlook.com/[Outlook.com] SMTP service:
 
 [source,text]
@@ -130,8 +128,8 @@ secrets:
     password: <password>
 --------------------------------------------------
 
-When sending emails, you must provide a from address, either as the default 
-in your account configuration or as part of the email action in the watch.
+When sending emails, you must provide a `from` address, either as the default 
+in your connector configuration or as part of the email action in the rule.
 
 NOTE:   You must use a unique App Password if two-step verification is enabled.
         See http://windows.microsoft.com/en-us/windows/app-passwords-two-step-verification[App
@@ -141,7 +139,7 @@ NOTE:   You must use a unique App Password if two-step verification is enabled.
 [[amazon-ses]]
 ===== Sending email from Amazon SES (Simple Email Service)
 
-Use the following email account settings to send email from the
+Use the following email connector configuration to send email from the
 http://aws.amazon.com/ses[Amazon Simple Email Service] (SES) SMTP service:
 
 [source,text]
@@ -168,7 +166,7 @@ NOTE:   You must use your Amazon SES SMTP credentials to send email through
 [[exchange]]
 ===== Sending email from Microsoft Exchange
 
-Use the following email account settings to send email action from Microsoft
+Use the following email connector configuration to send email from Microsoft
 Exchange:
 
 [source,text]

docs/user/alerting/action-types/index.asciidoc

@@ -1,11 +1,11 @@
 [role="xpack"]
 [[index-action-type]]
-=== Index action
+=== Index connector and action
 ++++
 <titleabbrev>Index</titleabbrev>
 ++++
 
-The index action type will index a document into {es}. See also the {ref}/indices-create-index.html[create index API].
+The index connector will index a document into {es}. See also the {ref}/indices-create-index.html[create index API].
 
 [float]
 [[index-connector-configuration]]
@@ -20,12 +20,12 @@ Execution time field::  This field will be automatically set to the time the ale
 
 [float]
 [[Preconfigured-index-configuration]]
-==== Preconfigured action type
+==== Preconfigured connector type
 
 [source,text]
 --
  my-index:
-   name: action-type-index
+   name: preconfigured-index-connector-type
    actionTypeId: .index
    config:
      index: .kibana
@@ -33,7 +33,7 @@ Execution time field::  This field will be automatically set to the time the ale
      executionTimeField: somedate
 --
 
-Config defines information for the action type.
+Config defines information for the connector type.
 
 `index`:: A string that corresponds to *Index*.
 `refresh`:: A boolean that corresponds to *Refresh*. Defaults to `false`.
@@ -51,19 +51,19 @@ Document::  The document to index in JSON format.
 [[index-action-example]]
 ==== Example
 
-Example of the index document for Index Threshold alert:
+Example of the index document for Index Threshold rule:
 
 [source,text]
 --------------------------------------------------
 {
+    "rule_id": "{{ruleId}}",
+    "rule_name": "{{ruleName}}",
     "alert_id": "{{alertId}}",
-    "alert_name": "{{alertName}}",
-    "alert_instance_id": "{{alertInstanceId}}",
     "context_message": "{{context.message}}"
 } 
 --------------------------------------------------
 
-Example of create test index using the API.
+Example of creating a test index using the API.
 
 [source,text]
 --------------------------------------------------
@@ -74,9 +74,9 @@ PUT test
     },
     "mappings" : {
         "properties" : {
+            "rule_id" : { "type" : "text" },
+            "rule_name" : { "type" : "text" },
             "alert_id" : { "type" : "text" },
-            "alert_name" : { "type" : "text" },
-            "alert_instance_id" : { "type" : "text" },
             "context_message": { "type" : "text" }
         }
     }

docs/user/alerting/action-types/jira.asciidoc

@@ -1,11 +1,11 @@
 [role="xpack"]
 [[jira-action-type]]
-=== Jira action
+=== Jira connector and action
 ++++
 <titleabbrev>Jira</titleabbrev>
 ++++
 
-The Jira action type uses the https://developer.atlassian.com/cloud/jira/platform/rest/v2/[REST API v2] to create Jira issues.
+The Jira connector uses the https://developer.atlassian.com/cloud/jira/platform/rest/v2/[REST API v2] to create Jira issues.
 
 [float]
 [[jira-connector-configuration]]
@@ -21,12 +21,12 @@ API token (or password)::  Jira API authentication token (or password) for HTTP
 
 [float]
 [[Preconfigured-jira-configuration]]
-==== Preconfigured action type
+==== Preconfigured connector type
 
 [source,text]
 --
  my-jira:
-   name: preconfigured-jira-action-type
+   name: preconfigured-jira-connector-type
    actionTypeId: .jira
    config:
      apiUrl: https://elastic.atlassian.net
@@ -36,12 +36,12 @@ API token (or password)::  Jira API authentication token (or password) for HTTP
      apiToken: tokenkeystorevalue
 --
 
-Config defines information for the action type.
+Config defines information for the connector type.
 
 `apiUrl`:: An address that corresponds to *URL*.
 `projectKey`:: A key that corresponds to *Project Key*.
 
-Secrets defines sensitive information for the action type.
+Secrets defines sensitive information for the connector type.
 
 `email`:: A string that corresponds to *Email*.
 `apiToken`:: A string that corresponds to *API Token*. Should be stored in the <<creating-keystore, {kib} keystore>>.

docs/user/alerting/action-types/pagerduty.asciidoc

@@ -1,11 +1,11 @@
 [role="xpack"]
 [[pagerduty-action-type]]
-=== PagerDuty action
+=== PagerDuty connector and action
 ++++
 <titleabbrev>PagerDuty</titleabbrev>
 ++++
 
-The PagerDuty action type uses the https://v2.developer.pagerduty.com/docs/events-api-v2[v2 Events API] to trigger, acknowledge, and resolve PagerDuty alerts.
+The PagerDuty connector uses the https://v2.developer.pagerduty.com/docs/events-api-v2[v2 Events API] to trigger, acknowledge, and resolve PagerDuty alerts.
 
 [float]
 [[pagerduty-connector-configuration]]
@@ -19,12 +19,12 @@ Integration Key::   A 32 character PagerDuty Integration Key for an integration
 
 [float]
 [[Preconfigured-pagerduty-configuration]]
-==== Preconfigured action type
+==== Preconfigured connector type
 
 [source,text]
 --
  my-pagerduty:
-   name: preconfigured-pagerduty-action-type
+   name: preconfigured-pagerduty-connector-type
    actionTypeId: .pagerduty
    config:
      apiUrl: https://test.host
@@ -32,11 +32,11 @@ Integration Key::   A 32 character PagerDuty Integration Key for an integration
      routingKey: testroutingkey
 --
 
-Config defines information for the action type.
+Config defines information for the connector type.
 
 `apiURL`:: A URL string that corresponds to *API URL*.
 
-Secrets defines sensitive information for the action type.
+Secrets defines sensitive information for the connector type.
 
 `routingKey`:: A string that corresponds to *Integration Key*.
 
@@ -62,11 +62,11 @@ For more details on these properties, see https://v2.developer.pagerduty.com/v2/
 [[pagerduty-benefits]]
 ==== Configure PagerDuty
 
-By integrating PagerDuty with alerts, you can:
+By integrating PagerDuty with rules, you can:
 
-* Route your alerts to the right PagerDuty responder within your team, based on your structure, escalation policies, and workflows.
-* Automatically generate incidents of different types and severity based on each alert’s context.
-* Tailor the incident data to match your needs by easily passing the alerting context from Kibana to PagerDuty.
+* Route your rules to the right PagerDuty responder within your team, based on your structure, escalation policies, and workflows.
+* Automatically generate incidents of different types and severity based on each rule’s context.
+* Tailor the incident data to match your needs by easily passing the rule context from Kibana to PagerDuty.
 
 [float]
 [[pagerduty-support]]
@@ -110,10 +110,9 @@ image::user/alerting/images/pagerduty-integration.png[PagerDuty Integrations tab
 
 . Create a PagerDuty Connector in Kibana.  You can:
 +
-* Create a connector as part of creating an alert by selecting PagerDuty in the *Actions*
-section of the alert configuration and selecting *Add new*.
-* Alternatively, create a connector. To create a connector, open the main menu, click *Stack Management* >
-Alerts and Actions*, select *Connectors*, click *Create connector*, then select the PagerDuty option.
+* Create a connector as part of creating an rule by selecting PagerDuty in the *Actions*
+section of the rule configuration and selecting *Add new*.
+* Alternatively, create a connector. To create a connector, open the main menu, click *Stack Management > Rules and Connectors*, select *Connectors*, click *Create connector*, then select the PagerDuty option.
 
 . Configure the connector by giving it a name and entering the Integration Key, optionally entering a custom API URL.
 +
@@ -122,15 +121,15 @@ See <<pagerduty-in-pagerduty, In PagerDuty>> for how to obtain the endpoint and
 
 . Save the Connector.
 
-. To create an alert, open the main menu, then click *Stack Management > Alerts and Actions* or the application of your choice.
+. To create a rule, open the main menu, then click *Stack Management > Rules and Connectors* or the application of your choice.
 
 . Set up an action using your PagerDuty connector, by determining:
 +
 * The action’s type: Trigger, Resolve, or Acknowledge.
 * The event’s severity: Info, warning, error, or critical.
-* An array of different fields, including the timestamp, group, class, component, and your dedup key. By default, the dedup is configured to create a new PagerDuty incident for each alert instance and reuse the incident when a recovered alert instance reactivates.
-Depending on your custom needs, assign them variables from the alerting context.
-To see the available context variables, click on the *Add alert variable* icon next
+* An array of different fields, including the timestamp, group, class, component, and your dedup key. By default, the dedup is configured to create a new PagerDuty incident for each alert and reuse the incident when a recovered alert reactivates.
+Depending on your custom needs, assign them variables from the rule context.
+To see the available context variables, click on the *Add variable* icon next
 to each corresponding field. For more details on these parameters, see the
 <<pagerduty-action-configuration, Actions Configuration>> and the PagerDuty
 https://v2.developer.pagerduty.com/v2/docs/send-an-event-events-api-v2[API v2 documentation].

docs/user/alerting/action-types/pre-configured-connectors.asciidoc

@@ -1,24 +1,20 @@
 [role="xpack"]
-[[pre-configured-action-types-and-connectors]]
+[[pre-configured-connectors]]
 
-=== Preconfigured connectors and action types
+=== Preconfigured connectors
 
-You can preconfigure a connector or action type to have all the information it needs prior to startup
-by adding it to the `kibana.yml` file.
+You can preconfigure a connector to have all the information it needs prior to startup by adding it to the `kibana.yml` file.
 
-Preconfigured connectors offer the following capabilities:
+Preconfigured connectors offer the following benefits:
 
 - Require no setup. Configuration and credentials needed to execute an
 action are predefined, including the connector name and ID.
 - Appear in all spaces because they are not saved objects.
 - Cannot be edited or deleted.
 
-A preconfigured action type has only preconfigured connectors. Preconfigured
-connectors can belong to either the preconfigured action type or to the regular action type.
-
 [float]
 [[preconfigured-connector-example]]
-==== Preconfigured connectors
+==== Preconfigured connectors example
 
 This example shows a valid configuration for
 two out-of-the box connectors: <<slack-action-type, Slack>> and <<webhook-action-type, Webhook>>.
@@ -44,78 +40,27 @@ two out-of-the box connectors: <<slack-action-type, Slack>> and <<webhook-action
         password: changeme
 ```
 
-<1>  The key is the action connector identifier, `my-slack1` in this example.
+<1>  The key is the connector identifier, `my-slack1` in this example.
 <2> `actionTypeId` is the action type identifier.
 <3> `name` is the name of the preconfigured connector.
-<4> `config` is the action type specific to the configuration.
-<5> `secrets` is sensitive configuration, such as username, password, and keys.
+<4> `config` is the configuration specific to the connector type.
+<5> `secrets` is the sensitive configuration, such as username, password, and keys, specific to the connector type.
 
 [NOTE]
 ==============================================
 Sensitive properties, such as passwords, can also be stored in the <<creating-keystore, {kib} keystore>>.
 ==============================================
 
-////
 [float]
 [[managing-pre-configured-connectors]]
 ==== View preconfigured connectors
-////
 
-When you open the main menu, click *Stack Management > Alerts and Actions*. Preconfigured connectors
-appear on the <<connector-management, *Connectors* tab>>,
-regardless of which space you are in.
-They are tagged as “preconfigured”, and you cannot delete them.
+When you open the main menu, click *Stack Management > Rules and Connectors*. Preconfigured connectors appear on the <<connector-management, *Connectors* tab>>, regardless of which space you are in. They are tagged as “preconfigured”, and you cannot delete them.
 
 [role="screenshot"]
-image::images/pre-configured-connectors-managing.png[Connectors managing tab with pre-cofigured]
+image::images/pre-configured-connectors-managing.png[Connectors managing tab with pre-configured]
 
-Clicking a preconfigured connector shows the description, but not the configuration.
-A message indicates that this is a preconfigured connector.
+Clicking a preconfigured connector shows the description, but not the configuration. A message indicates that this is a preconfigured connector.
 
 [role="screenshot"]
 image::images/pre-configured-connectors-view-screen.png[Pre-configured connector view details]
-
-The connector details preview is disabled for preconfigured connectors
-of a preconfigured action type.
-
-[role="screenshot"]
-image::images/pre-configured-action-type-managing.png[Connectors managing tab with pre-cofigured]
-
-[float]
-[[preconfigured-action-type-example]]
-==== Preconfigured action type
-
-This example shows a preconfigured action type with one out-of-the box connector.
-
-```js
-  xpack.actions.enabledActionTypes: ['.slack', '.email', '.index'] <1>
-  xpack.actions.preconfigured:                                     <2>
-    my-server-log:
-      actionTypeId: .server-log
-      name: 'Server log #xyz'
-```
-
-<1> `enabledActionTypes` prevents the preconfigured action type from creating and deleting connectors. For more details, check <<action-settings, Action settings>>.
-<2> `preconfigured` is the setting for defining the list of available connectors for the preconfigured action type.
-
-[[managing-pre-configured-action-types]]
-To attach a preconfigured action to an alert:
-
-. Open the main menu, click *Stack Management > Alerts and Actions*, then open the *Connectors* tab.
-
-. Click *Create connector.*
-
-. In the list of available action types, select the preconfigured action type you want.
-+
-[role="screenshot"]
-image::images/pre-configured-action-type-select-type.png[Pre-configured connector create menu]
-
-. In *Create alert*, open the connector dropdown, and then select the preconfigured
-connector.
-+
-The `preconfigured` label distinguishes it from a space-aware connector.
-+
-[role="screenshot"]
-image::images/alert-pre-configured-connectors-dropdown.png[Dropdown list with pre-cofigured connectors]
-
-. Click *Add action*.

docs/user/alerting/action-types/resilient.asciidoc

@@ -1,11 +1,11 @@
 [role="xpack"]
 [[resilient-action-type]]
-=== IBM Resilient action
+=== IBM Resilient connector and action
 ++++
 <titleabbrev>IBM Resilient</titleabbrev>
 ++++
 
-The IBM Resilient action type uses the https://developer.ibm.com/security/resilient/rest/[RESILIENT REST v2] to create IBM Resilient incidents.
+The IBM Resilient connector uses the https://developer.ibm.com/security/resilient/rest/[RESILIENT REST v2] to create IBM Resilient incidents.
 
 [float]
 [[resilient-connector-configuration]]
@@ -21,12 +21,12 @@ API key secret::  The authentication key secret for HTTP Basic authentication.
 
 [float]
 [[Preconfigured-resilient-configuration]]
-==== Preconfigured action type
+==== Preconfigured connector type
 
 [source,text]
 --
  my-resilient:
-   name: preconfigured-resilient-action-type
+   name: preconfigured-resilient-connector-type
    actionTypeId: .resilient
    config:
      apiUrl: https://elastic.resilient.net
@@ -36,12 +36,12 @@ API key secret::  The authentication key secret for HTTP Basic authentication.
      apiKeySecret: tokenkeystorevalue
 --
 
-Config defines information for the action type.
+Config defines information for the connector type.
 
 `apiUrl`:: An address that corresponds to *URL*.
 `orgId`:: An ID that corresponds to *Organization ID*.
 
-Secrets defines sensitive information for the action type.
+Secrets defines sensitive information for the connector type.
 
 `apiKeyId`:: A string that corresponds to *API key ID*.
 `apiKeySecret`:: A string that corresponds to *API Key secret*. Should be stored in the <<creating-keystore, {kib} keystore>>.

docs/user/alerting/action-types/server-log.asciidoc

@@ -1,11 +1,11 @@
 [role="xpack"]
 [[server-log-action-type]]
-=== Server log action
+=== Server log connector and action
 ++++
 <titleabbrev>Server log</titleabbrev>
 ++++
 
-This action type writes an entry to the {kib} server log.
+This connector writes an entry to the {kib} server log.
 
 [float]
 [[server-log-connector-configuration]]
@@ -17,12 +17,12 @@ Name::      The name of the connector. The name is used to identify a  connector
 
 [float]
 [[Preconfigured-server-log-configuration]]
-==== Preconfigured action type
+==== Preconfigured connector type
 
 [source,text]
 --
  my-server-log:
-   name: test
+   name: preconfigured-server-log-connector-type
    actionTypeId: .server-log
 --
 

docs/user/alerting/action-types/servicenow.asciidoc

@@ -1,11 +1,11 @@
 [role="xpack"]
 [[servicenow-action-type]]
-=== ServiceNow action
+=== ServiceNow connector and action
 ++++
 <titleabbrev>ServiceNow</titleabbrev>
 ++++
 
-The ServiceNow action type uses the https://developer.servicenow.com/app.do#!/rest_api_doc?v=orlando&id=c_TableAPI[V2 Table API] to create ServiceNow incidents.
+The ServiceNow connector uses the https://developer.servicenow.com/app.do#!/rest_api_doc?v=orlando&id=c_TableAPI[V2 Table API] to create ServiceNow incidents.
 
 [float]
 [[servicenow-connector-configuration]]
@@ -20,12 +20,12 @@ Password::  Password for HTTP Basic authentication.
 
 [float]
 [[Preconfigured-servicenow-configuration]]
-==== Preconfigured action type
+==== Preconfigured connector type
 
 [source,text]
 --
  my-servicenow:
-   name: preconfigured-servicenow-action-type
+   name: preconfigured-servicenow-connector-type
    actionTypeId: .servicenow
    config:
      apiUrl: https://dev94428.service-now.com/
@@ -34,11 +34,11 @@ Password::  Password for HTTP Basic authentication.
      password: passwordkeystorevalue
 --
 
-Config defines information for the action type.
+Config defines information for the connector type.
 
 `apiUrl`:: An address that corresponds to *URL*.
 
-Secrets defines sensitive information for the action type.
+Secrets defines sensitive information for the connector type.
 
 `username`:: A string that corresponds to *Username*.
 `password`::  A string that corresponds to *Password*. Should be stored in the <<creating-keystore, {kib} keystore>>.

docs/user/alerting/action-types/slack.asciidoc

@@ -1,11 +1,11 @@
 [role="xpack"]
 [[slack-action-type]]
-=== Slack action
+=== Slack connector and action
 ++++
 <titleabbrev>Slack</titleabbrev>
 ++++
 
-The Slack action type uses https://api.slack.com/incoming-webhooks[Slack Incoming Webhooks].
+The Slack connector uses https://api.slack.com/incoming-webhooks[Slack Incoming Webhooks].
 
 [float]
 [[slack-connector-configuration]]
@@ -18,18 +18,18 @@ Webhook URL::   The URL of the incoming webhook. See https://api.slack.com/messa
 
 [float]
 [[Preconfigured-slack-configuration]]
-==== Preconfigured action type
+==== Preconfigured connector type
 
 [source,text]
 --
  my-slack:
-   name: preconfigured-slack-action-type
+   name: preconfigured-slack-connector-type
    actionTypeId: .slack
    secrets:
      webhookUrl: 'https://hooks.slack.com/services/abcd/efgh/ijklmnopqrstuvwxyz'
 --
 
-Secrets defines sensitive information for the action type.
+Secrets defines sensitive information for the connector type.
 
 `webhookUrl`:: A string that corresponds to *Webhook URL*.
 

docs/user/alerting/action-types/teams.asciidoc

@@ -1,11 +1,11 @@
 [role="xpack"]
 [[teams-action-type]]
-=== Microsoft Teams action
+=== Microsoft Teams connector and action
 ++++
 <titleabbrev>Microsoft Teams</titleabbrev>
 ++++
 
-The Microsoft Teams action type uses https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook[Incoming Webhooks].
+The Microsoft Teams connector uses https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook[Incoming Webhooks].
 
 [float]
 [[teams-connector-configuration]]
@@ -18,18 +18,18 @@ Webhook URL::   The URL of the incoming webhook. See https://docs.microsoft.com/
 
 [float]
 [[Preconfigured-teams-configuration]]
-==== Preconfigured action type
+==== Preconfigured connector type
 
 [source,text]
 --
  my-teams:
-   name: preconfigured-teams-action-type
+   name: preconfigured-teams-connector-type
    actionTypeId: .teams
    secrets:
      webhookUrl: 'https://outlook.office.com/webhook/abcd@0123456/IncomingWebhook/abcdefgh/ijklmnopqrstuvwxyz'
 --
 
-Secrets defines sensitive information for the action type.
+Secrets defines sensitive information for the connector type.
 
 `webhookUrl`:: A string that corresponds to *Webhook URL*.
 

docs/user/alerting/action-types/webhook.asciidoc

@@ -1,11 +1,11 @@
 [role="xpack"]
 [[webhook-action-type]]
-=== Webhook action
+=== Webhook connector and action
 ++++
 <titleabbrev>Webhook</titleabbrev>
 ++++
 
-The Webhook action type uses https://github.com/axios/axios[axios] to send a POST or PUT request to a web service.
+The Webhook connector uses https://github.com/axios/axios[axios] to send a POST or PUT request to a web service.
 
 [float]
 [[webhook-connector-configuration]]
@@ -23,12 +23,12 @@ Password::  Password for HTTP basic authentication.
 
 [float]
 [[Preconfigured-webhook-configuration]]
-==== Preconfigured action type
+==== Preconfigured connector type
 
 [source,text]
 --
  my-webhook:
-   name: preconfigured-webhook-action-type
+   name: preconfigured-webhook-connector-type
    actionTypeId: .webhook
    config:
      url: https://test.host
@@ -40,14 +40,14 @@ Password::  Password for HTTP basic authentication.
      password: passwordkeystorevalue
 --
 
-Config defines information for the action type.
+Config defines information for the connector type.
 
 `url`:: A URL string that corresponds to *URL*.
 `method`:: A string that corresponds to *Method*.
 `headers`:: A record<string, string> that corresponds to *Headers*.
 `hasAuth`:: A boolean that corresponds to *Requires authentication*. If `true`, this connector will require values for `user` and `password` inside the secrets configuration. Defaults to `true`.
 
-Secrets defines sensitive information for the action type.
+Secrets defines sensitive information for the connector type.
 
 `user`:: A string that corresponds to *User*. Required if `hasAuth` is set to `true`.
 `password`:: A string that corresponds to *Password*. Should be stored in the <<creating-keystore, {kib} keystore>>. Required if `hasAuth` is set to `true`.

docs/user/alerting/alert-types.asciidoc

@@ -1,42 +0,0 @@
-[role="xpack"]
-[[alert-types]]
-== Alerts
-
-Kibana provides two types of alerts:
-
-* Stack alerts, which are built into {kib}
-* Domain-specific alerts, which are registered by {kib} apps.
-
-[float]
-==== Standard stack alerts
-
-{kib} provides two stack alerts: 
-
-* <<alert-type-index-threshold>>
-* <<alert-type-es-query>>
-
-Users require the `all` privilege to access the *Stack Alerts* feature and create and edit alerts.
-See <<kibana-feature-privileges, feature privileges>> for more information.
-
-[float]
-==== Domain-specific alerts
-
-For domain-specific alerts, refer to the documentation for that app.
-{kib} supports these alerts:
-
-* {observability-guide}/create-alerts.html[Observability alerts]
-* {security-guide}/prebuilt-rules.html[Security alerts]
-* <<geo-alerting, Maps alerts>>
-* {ml-docs}/ml-configuring-alerts.html[{ml-cap} alerts] beta:[]
-
-[NOTE]
-==============================================
-Some alert types are subscription features, while others are free features.
-For a comparison of the Elastic subscription levels,
-see {subscriptions}[the subscription page].
-==============================================
-
-
-include::stack-alerts/index-threshold.asciidoc[]
-include::stack-alerts/es-query.asciidoc[]
-include::maps-alerts/geo-alert-types.asciidoc[]

docs/user/alerting/alerting-getting-started.asciidoc

@@ -1,13 +1,13 @@
 [role="xpack"]
 [[alerting-getting-started]]
-= Alerting and Actions
+= Alerting
 
 
 --
 
-Alerting allows you to detect complex conditions within different {kib} apps and trigger actions when those conditions are met. Alerting is integrated with {observability-guide}/create-alerts.html[*Observability*], {security-guide}/prebuilt-rules.html[*Security*], <<geo-alerting,*Maps*>> and {ml-docs}/ml-configuring-alerts.html[*{ml-app}*], can be centrally managed from the <<management,*Management*>> UI, and provides a set of built-in <<action-types, actions>> and <<alert-types, alerts>> (known as stack alerts) for you to use.
+Alerting allows you to define *rules* to detect complex conditions within different {kib} apps and trigger actions when those conditions are met. Alerting is integrated with {observability-guide}/create-alerts.html[*Observability*], {security-guide}/prebuilt-rules.html[*Security*], <<geo-alerting,*Maps*>> and {ml-docs}/ml-configuring-alerts.html[*{ml-app}*], can be centrally managed from the <<management,*Management*>> UI, and provides a set of built-in <<action-types, connectors>> and <<rule-types, rules>> (known as stack rules) for you to use.
 
-image::images/alerting-overview.png[Alerts and actions UI]
+image::images/alerting-overview.png[Rules and Connectors UI]
 
 [IMPORTANT]
 ==============================================
@@ -17,120 +17,119 @@ To make sure you can access alerting and actions, see the <<alerting-setup-prere
 [float]
 == Concepts and terminology
 
-*Alerts* work by running checks on a schedule to detect conditions. When a condition is met, the alert tracks it as an *alert instance* and responds by triggering one or more *actions*. 
+Alerting works by running checks on a schedule to detect conditions defined by a *rule*. When a condition is met, the rule tracks it as an *alert* and responds by triggering one or more *actions*.
 Actions typically involve interaction with {kib} services or third party integrations. *Connectors* allow actions to talk to these services and integrations. 
-This section describes all of these elements and how they operate together. 
+This section describes all of these elements and how they operate together.
 
 [float]
-=== What is an alert?
+=== What is a rule?
 
-An alert specifies a background task that runs on the {kib} server to check for specific conditions. It consists of three main parts: 
+A rule specifies a background task that runs on the {kib} server to check for specific conditions. It consists of three main parts: 
 
 * *Conditions*: what needs to be detected?
 * *Schedule*: when/how often should detection checks run?
 * *Actions*: what happens when a condition is detected?
 
-For example, when monitoring a set of servers, an alert might check for average CPU usage > 0.9 on each server for the two minutes (condition), checked every minute (schedule), sending a warning email message via SMTP with subject `CPU on {{server}} is high` (action).
+For example, when monitoring a set of servers, a rule might check for average CPU usage > 0.9 on each server for the last two minutes (condition), checked every minute (schedule), sending a warning email message via SMTP with subject `CPU on {{server}} is high` (action).
 
-image::images/what-is-an-alert.svg[Three components of an alert]
+image::images/what-is-a-rule.svg[Three components of a rule]
 
-The following sections each part of the alert is described in more detail.
+The following sections describe each part of the rule in more detail.
 
 [float]
 [[alerting-concepts-conditions]]
 ==== Conditions
 
-Under the hood, {kib} alerts detect conditions by running javascript function on the {kib} server, which gives it flexibility to support a wide range of detections, anything from the results of a simple {es} query to heavy computations involving data from multiple sources or external systems. 
+Under the hood, {kib} rules detect conditions by running a javascript function on the {kib} server, which gives it the flexibility to support a wide range of conditions, anything from the results of a simple {es} query to heavy computations involving data from multiple sources or external systems. 
 
-These detections are packaged and exposed as *alert types*. An alert type hides the underlying details of the detection, and exposes a set of parameters
-to control the details of the conditions to detect. 
+These conditions are packaged and exposed as *rule types*. A rule type hides the underlying details of the condition, and exposes a set of parameters
+to control the details of the conditions to detect.
 
-For example, an <<alert-types, index threshold alert type>> lets you specify the index to query, an aggregation field, and a time window, but the details of the underlying {es} query are hidden.
+For example, an <<rule-type-index-threshold, index threshold rule type>> lets you specify the index to query, an aggregation field, and a time window, but the details of the underlying {es} query are hidden.
 
-See <<alert-types>> for the types of alerts provided by {kib} and how they express their conditions.
+See <<rule-types>> for the types of rules provided by {kib} and how they express their conditions.
 
 [float]
 [[alerting-concepts-scheduling]]
 ==== Schedule
 
-Alert schedules are defined as an interval between subsequent checks, and can range from a few seconds to months. 
+Rule schedules are defined as an interval between subsequent checks, and can range from a few seconds to months.
 
 [IMPORTANT]
 ==============================================
-The intervals of alert checks in {kib} are approximate, their timing of their execution is affected by factors such as the frequency at which tasks are claimed and the task load on the system. See <<alerting-production-considerations>> for more information. 
+The intervals of rule checks in {kib} are approximate. The timing of their execution is affected by factors such as the frequency at which tasks are claimed and the task load on the system. See <<alerting-production-considerations, Alerting production considerations>> for more information.
 ==============================================
 
 [float]
 [[alerting-concepts-actions]]
 ==== Actions
 
-Actions are invocations of {kib} services or integrations with third-party systems, that run as background tasks on the {kib} server when alert conditions are met. 
+Actions are invocations of connectors, which allow interaction with {kib} services or integrations with third-party systems. Actions run as background tasks on the {kib} server when rule conditions are met. 
 
-When defining actions in an alert, you specify:
+When defining actions in a rule, you specify:
 
-* the *action type*: the type of service or integration to use
-* the connection for that type by referencing a  <<alerting-concepts-connectors, connector>>
-* a mapping of alert values to properties exposed for that type of action
+* the *connector type*: the type of service or integration to use
+* the connection for that type by referencing a <<alerting-concepts-connectors, connector>>
+* a mapping of rule values to properties exposed for that type of action
 
-The result is a template: all the parameters needed to invoke a service are supplied except for specific values that are only known at the time the alert condition is detected. 
+The result is a template: all the parameters needed to invoke a service are supplied except for specific values that are only known at the time the rule condition is detected. 
 
-In the server monitoring example, the `email` action type is used, and `server` is mapped to the body of the email, using the template string `CPU on {{server}} is high`.
+In the server monitoring example, the `email` connector type is used, and `server` is mapped to the body of the email, using the template string `CPU on {{server}} is high`.
 
-When the alert detects the condition, it creates an <<alerting-concepts-alert-instances, alert instance>> containing the details of the condition, renders the template with these details such as server name, and executes the action on the {kib} server by invoking the `email` action type. 
+When the rule detects the condition, it creates an <<alerting-concepts-alert-instances, alert>> containing the details of the condition, renders the template with these details such as server name, and executes the action on the {kib} server by invoking the `email` connector type. 
 
 image::images/what-is-an-action.svg[Actions are like templates that are rendered when an alert detects a condition]
 
-See <<action-types>> for details on the types of actions provided by {kib}. 
+See <<action-types>> for details on the types of connectors provided by {kib}.
 
 [float]
 [[alerting-concepts-alert-instances]]
-=== Alert instances
+=== Alerts
 
-When checking for a condition, an alert might identify multiple occurrences of the condition. {kib} tracks each of these *alert instances* separately and takes action per instance. 
+When checking for a condition, a rule might identify multiple occurrences of the condition. {kib} tracks each of these *alerts* separately and takes an action per alert.
 
-Using the server monitoring example, each server with average CPU > 0.9 is tracked as an alert instance. This means a separate email is sent for each server that exceeds the threshold. 
+Using the server monitoring example, each server with average CPU > 0.9 is tracked as an alert. This means a separate email is sent for each server that exceeds the threshold.
 
-image::images/alert-instances.svg[{kib} tracks each detected condition as an alert instance and takes action on each instance]
+image::images/alerts.svg[{kib} tracks each detected condition as an alert and takes action on each alert]
 
 [float]
 [[alerting-concepts-suppressing-duplicate-notifications]]
 === Suppressing duplicate notifications
 
-Since actions are taken per instance, alerts can end up generating a large number of actions. Take the following example where an alert is monitoring three servers every minute for CPU usage > 0.9: 
-
-* Minute 1: server X123 > 0.9. *One email* is sent for server X123. 
-* Minute 2: X123 and Y456 > 0.9. *Two emails* are sent, on for X123 and one for Y456.
-* Minute 3: X123, Y456, Z789 > 0.9. *Three emails* are sent, one for each of X123, Y456, Z789.
-
-In the above example, three emails are sent for server X123 in the span of 3 minutes for the same condition. Often it's desirable to suppress frequent re-notification. Operations like muting and re-notification throttling can be applied at the instance level. If we set the alert re-notify interval to 5 minutes, we reduce noise by only getting emails for new servers that exceed the threshold: 
+Since actions are executed per alert, a rule can end up generating a large number of actions. Take the following example where a rule is monitoring three servers every minute for CPU usage > 0.9:
 
 * Minute 1: server X123 > 0.9. *One email* is sent for server X123.
-* Minute 2: X123 and Y456 > 0.9. *One email* is sent for Y456 
-* Minute 3: X123, Y456, Z789 > 0.9. *One email* is sent for Z789. 
+* Minute 2: X123 and Y456 > 0.9. *Two emails* are sent, one for X123 and one for Y456.
+* Minute 3: X123, Y456, Z789 > 0.9. *Three emails* are sent, one for each of X123, Y456, Z789.
+
+In the above example, three emails are sent for server X123 in the span of 3 minutes for the same rule. Often it's desirable to suppress frequent re-notification. Operations like muting and throttling can be applied at the alert level. If we set the rule re-notify interval to 5 minutes, we reduce noise by only getting emails for new servers that exceed the threshold:
+
+* Minute 1: server X123 > 0.9. *One email* is sent for server X123.
+* Minute 2: X123 and Y456 > 0.9. *One email* is sent for Y456.
+* Minute 3: X123, Y456, Z789 > 0.9. *One email* is sent for Z789.
 
 [float]
 [[alerting-concepts-connectors]]
 === Connectors
 
-Actions often involve connecting with services inside {kib} or integrations with third-party systems.
-Rather than repeatedly entering connection information and credentials for each action, {kib} simplifies action setup using *connectors*. 
+Actions often involve connecting with services inside {kib} or integrating with third-party systems.
+Rather than repeatedly entering connection information and credentials for each action, {kib} simplifies action setup using *connectors*.
 
-*Connectors* provide a central place to store connection information for services and integrations. For example if four alerts send email notifications via the same SMTP service, 
-they all reference the same SMTP connector. When the SMTP settings change they are updated once in the connector, instead of having to update four alerts. 
+*Connectors* provide a central place to store connection information for services and integrations. For example if four rules send email notifications via the same SMTP service, they can all reference the same SMTP connector. When the SMTP settings change, you can update them once in the connector, instead of having to update four rules.
 
-image::images/alert-concepts-connectors.svg[Connectors provide a central place to store service connection settings]
+image::images/rule-concepts-connectors.svg[Connectors provide a central place to store service connection settings]
 
 [float]
 === Summary
 
-An _alert_ consists of conditions, _actions_, and a schedule. When conditions are met, _alert instances_ are created that render _actions_ and invoke them. To make action setup and update easier, actions refer to _connectors_ that centralize the information used to connect with {kib} services and third-party integrations. The following example ties these concepts together: 
+A *rule* consists of conditions, *actions*, and a schedule. When conditions are met, *alerts* are created that render *actions* and invoke them. To make action setup and update easier, actions use *connectors* that centralize the information used to connect with {kib} services and third-party integrations. The following example ties these concepts together:
 
-image::images/alert-concepts-summary.svg[Alerts, actions, alert instances and connectors work together to convert detection into action]
+image::images/rule-concepts-summary.svg[Rules, connectors, alerts and actions work together to convert detection into action]
 
-. Anytime an *alert*'s conditions are met, an *alert instance* is created.  This example checks for servers with average CPU > 0.9. Three servers meet the condition, so three instances are created. 
-. Instances create *actions* as long as they are not muted or throttled. When actions are created, the template that was setup in the alert is filled with actual values.  In this example three actions are created, and the template string {{server}} is replaced with the server name for each instance. 
-. {kib} invokes the actions, sending them to a 3rd party *integration* like an email service.
-. If the 3rd party integration has connection parameters or credentials, {kib} will fetch these from the *connector* referenced in the action. 
+. Anytime a *rule*'s conditions are met, an *alert* is created.  This example checks for servers with average CPU > 0.9. Three servers meet the condition, so three alerts are created. 
+. Alerts create *actions* as long as they are not muted or throttled. When actions are created, the template that was setup in the rule is filled with actual values. In this example, three actions are created, and the template string {{server}} is replaced with the server name for each alert.
+. {kib} invokes the actions, sending them to a third party *integration* like an email service.
+. If the third party integration has connection parameters or credentials, {kib} will fetch these from the *connector* referenced in the action.
 
 
 [float]
@@ -139,17 +138,17 @@ image::images/alert-concepts-summary.svg[Alerts, actions, alert instances and co
 
 {kib} alerting and <<watcher-ui, {es} alerting>> are both used to detect conditions and can trigger actions in response, but they are completely independent alerting systems.
 
-This section will clarify some of the important differences in the function and intent of the two systems. 
+This section will clarify some of the important differences in the function and intent of the two systems.
 
 Functionally, {kib} alerting differs in that: 
 
 * Scheduled checks are run on {kib} instead of {es}
-* {kib} <<alerting-concepts-conditions, alerts hide the details of detecting conditions>> through *alert types*, whereas watches provide low-level control over inputs, conditions, and transformations. 
-* {kib} alerts tracks and persists the state of each detected condition through *alert instances*. This makes it possible to mute and throttle individual instances, and detect changes in state such as resolution. 
-* Actions are linked to *alert instances* in {kib} alerting. Actions are fired for each occurrence of a detected condition, rather than for the entire alert. 
+* {kib} <<alerting-concepts-conditions, rules hide the details of detecting conditions>> through *rule types*, whereas watches provide low-level control over inputs, conditions, and transformations.
+* {kib} rules track and persist the state of each detected condition through *alerts*. This makes it possible to mute and throttle individual alerts, and detect changes in state such as resolution.
+* Actions are linked to *alerts* in {kib} alerting. Actions are fired for each occurrence of a detected condition, rather than for the entire rule.
 
-At a higher level, {kib} alerts allow rich integrations across use cases like <<xpack-apm,*APM*>>, <<metrics-app,*Metrics*>>, <<xpack-siem,*Security*>>, and <<uptime-app,*Uptime*>>.
-Pre-packaged *alert types* simplify setup, hide the details complex domain-specific detections, while providing a consistent interface across {kib}.
+At a higher level, {kib} alerting allows rich integrations across use cases like <<xpack-apm,*APM*>>, <<metrics-app,*Metrics*>>, <<xpack-siem,*Security*>>, and <<uptime-app,*Uptime*>>.
+Pre-packaged *rule types* simplify setup and hide the details of complex, domain-specific detections, while providing a consistent interface across {kib}.
 
 [float]
 [[alerting-setup-prerequisites]]
@@ -162,13 +161,13 @@ If you are using an *on-premises* Elastic Stack deployment:
 
 If you are using an *on-premises* Elastic Stack deployment with <<using-kibana-with-security, *security*>>:
 
-* You must enable Transport Layer Security (TLS) for communication <<configuring-tls-kib-es, between {es} and {kib}>>. {kib} alerting uses <<api-keys, API keys>> to secure background alert checks and actions, and API keys require {ref}/configuring-tls.html#tls-http[TLS on the HTTP interface]. A proxy will not suffice.
+* You must enable Transport Layer Security (TLS) for communication <<configuring-tls-kib-es, between {es} and {kib}>>. {kib} alerting uses <<api-keys, API keys>> to secure background rule checks and actions, and API keys require {ref}/configuring-tls.html#tls-http[TLS on the HTTP interface]. A proxy will not suffice.
 
 [float]
 [[alerting-setup-production]]
 == Production considerations and scaling guidance
 
-When relying on alerts and actions as mission critical services, make sure you follow the <<alerting-production-considerations,Alerting production considerations>>.
+When relying on alerting and actions as mission critical services, make sure you follow the <<alerting-production-considerations,Alerting production considerations>>.
 
 See <<alerting-scaling-guidance>> for more information on the scalability of {kib} alerting.
 
@@ -187,29 +186,29 @@ To access alerting in a space, a user must have access to one of the following f
 * <<uptime-app,*Uptime*>>
 
 See <<kibana-feature-privileges, feature privileges>> for more information on configuring roles that provide access to these features.
-Also note that a user will need +read+ privileges for the *Actions and Connectors* feature to attach actions to an alert or to edit an alert that has an action attached to it.
+Also note that a user will need +read+ privileges for the *Actions and Connectors* feature to attach actions to a rule or to edit a rule that has an action attached to it.
 
 [float]
 [[alerting-spaces]]
 === Space isolation
 
-Alerts and connectors are isolated to the {kib} space in which they were created. An alert or connector created in one space will not be visible in another. 
+Rules and connectors are isolated to the {kib} space in which they were created. A rule or connector created in one space will not be visible in another. 
 
 [float]
 [[alerting-authorization]]
 === Authorization
 
-Alerts, including all background detection and the actions they generate are authorized using an <<api-keys, API key>> associated with the last user to edit the alert. Upon creating or modifying an alert, an API key is generated for that user, capturing a snapshot of their privileges at that moment in time. The API key is then used to run all background tasks associated with the alert including detection checks and executing actions. 
+Rules, including all background detection and the actions they generate are authorized using an <<api-keys, API key>> associated with the last user to edit the rule. Upon creating or modifying a rule, an API key is generated for that user, capturing a snapshot of their privileges at that moment in time. The API key is then used to run all background tasks associated with the rule including detection checks and executing actions. 
 
 [IMPORTANT]
 ==============================================
-If an alert requires certain privileges to run such as index privileges, keep in mind that if a user without those privileges updates the alert, the alert will no longer function.  
+If a rule requires certain privileges to run, such as index privileges, keep in mind that if a user without those privileges updates the rule, the rule will no longer function.  
 ==============================================
 
 [float]
 [[alerting-restricting-actions]]
 === Restricting actions
 
-For security reasons you may wish to limit the extent to which {kib} can connect to external services. <<action-settings>> allows you to disable certain <<action-types>> and allowlist the hostnames that {kib} can connect with. 
+For security reasons you may wish to limit the extent to which {kib} can connect to external services. <<action-settings>> allows you to disable certain <<action-types>> and allowlist the hostnames that {kib} can connect with.
 
 --

docs/user/alerting/alerting-troubleshooting.asciidoc

@@ -10,46 +10,46 @@ If your problem isn’t described here, please review open issues in the followi
 Have a question? Contact us in the https://discuss.elastic.co/[discuss forum].
 
 [float]
-[[alerts-small-check-interval-run-late]]
-=== Alerts with small check intervals run late
+[[rules-small-check-interval-run-late]]
+=== Rules with small check intervals run late
 
 *Problem*:
 
-Alerts with a small check interval, such as every two seconds, run later than scheduled.
+Rules with a small check interval, such as every two seconds, run later than scheduled.
 
 *Resolution*:
 
-Alerts run as background tasks at a cadence defined by their *check interval*.
-When an Alert *check interval* is smaller than the Task Manager <<task-manager-settings,`poll_interval`>> the alert will run late.
+Rules run as background tasks at a cadence defined by their *check interval*.
+When a Rule *check interval* is smaller than the Task Manager <<task-manager-settings,`poll_interval`>> the rule will run late.
 
-Either tweak the <<task-manager-settings,{kib} Task Manager settings>> or increase the *check interval* of the alerts in question.
+Either tweak the <<task-manager-settings,{kib} Task Manager settings>> or increase the *check interval* of the rules in question.
 
 For more details, see <<task-manager-health-scheduled-tasks-small-schedule-interval-run-late>>.
 
 
 [float]
-[[scheduled-alerts-run-late]]
-=== Alerts run late
+[[scheduled-rules-run-late]]
+=== Rules run late
 
 *Problem*:
 
-Scheduled alerts run at an inconsistent cadence, often running late.
+Scheduled rules run at an inconsistent cadence, often running late.
 
-Actions run long after the status of an alert changes, sending a notification of the change too late.
+Actions run long after the status of a rule changes, sending a notification of the change too late.
 
 *Solution*:
 
-Alerts and actions run as background tasks by each {kib} instance at a default rate of ten tasks every three seconds.
+Rules and actions run as background tasks by each {kib} instance at a default rate of ten tasks every three seconds.
 
-If many alerts or actions are scheduled to run at the same time, pending tasks will queue in {es}. Each {kib} instance then polls for pending tasks at a rate of up to ten tasks at a time, at three second intervals. Because alerts and actions are backed by tasks, it is possible for pending tasks in the queue to exceed this capacity and run late.
+If many rules or actions are scheduled to run at the same time, pending tasks will queue in {es}. Each {kib} instance then polls for pending tasks at a rate of up to ten tasks at a time, at three second intervals. Because rules and actions are backed by tasks, it is possible for pending tasks in the queue to exceed this capacity and run late.
 
 For details on diagnosing the underlying causes of such delays, see <<task-manager-health-tasks-run-late>>.
 
 Alerting and action tasks are identified by their type.
 
-* Alert tasks always begin with `alerting:`. For example, the `alerting:.index-threshold` tasks back the <<alert-type-index-threshold, index threshold stack alert>>.
+* Alerting tasks always begin with `alerting:`. For example, the `alerting:.index-threshold` tasks back the <<rule-type-index-threshold, index threshold stack rule>>.
 * Action tasks always begin with `actions:`. For example, the `actions:.index` tasks back the <<index-action-type, index action>>.
 
-When diagnosing issues related to Alerting, focus on the thats that begin with `alerting:` and `actions:`.
+When diagnosing issues related to Alerting, focus on the tasks that begin with `alerting:` and `actions:`.
 
 For more details on monitoring and diagnosing task execution in Task Manager, see <<task-manager-health-monitoring>>.

docs/user/alerting/defining-alerts.asciidoc

@@ -1,115 +0,0 @@
-[role="xpack"]
-[[defining-alerts]]
-== Defining alerts
-
-{kib} alerts can be created in a variety of apps including <<xpack-apm,*APM*>>, <<xpack-ml,*{ml-app}*>>, <<metrics-app,*Metrics*>>, <<xpack-siem,*Security*>>, <<uptime-app,*Uptime*>> and from <<management,*Management*>> UI. While alerting details may differ from app to app, they share a common interface for defining and configuring alerts that this section describes in more detail.
-
-[float]
-=== Create an alert
-
-When you create an alert, you must define the alert details, conditions, and actions.
-
-. <<defining-alerts-general-details, General alert details>>
-. <<defining-alerts-type-conditions, Alert type and conditions>>
-. <<defining-alerts-actions-details, Action type and action details>>
-
-image::images/alert-flyout-sections.png[The three sections of an alert definition]
-
-[float]
-[[defining-alerts-general-details]]
-=== General alert details
-
-All alerts share the following four properties.
-
-[role="screenshot"]
-image::images/alert-flyout-general-details.png[alt='All alerts have name, tags, check every, and notify properties in common']
-
-Name::      The name of the alert. While this name does not have to be unique, the name can be referenced in actions and also appears in the searchable alert listing in the management UI. A distinctive name can help identify and find an alert.
-Tags::      A list of tag names that can be applied to an alert. Tags can help you organize and find alerts, because tags appear in the alert listing in the management UI which is searchable by tag.
-Check every::      This value determines how frequently the alert conditions below are checked. Note that the timing of background alert checks are not guaranteed, particularly for intervals of less than 10 seconds. See <<alerting-production-considerations>> for more information.
-Notify::      This value limits how often actions are repeated when an alert instance remains active across alert checks. See <<alerting-concepts-suppressing-duplicate-notifications>> for more information. +
-- **Only on status change**: Actions are not repeated when an alert instance remains active across checks. Actions run only when the alert status changes.
-- **Every time alert is active**: Actions are repeated when an alert instance remains active across checks.
-- **On a custom action interval**: Actions are suppressed for the throttle interval, but repeat when an alert instance remains active across checks for a duration longer than the throttle interval.
-
-
-[float]
-[[defining-alerts-type-conditions]]
-=== Alert type and conditions
-
-Depending upon the {kib} app and context, you may be prompted to choose the type of alert you wish to create. Some apps will pre-select the type of alert for you.
-
-[role="screenshot"]
-image::images/alert-flyout-alert-type-selection.png[Choosing the type of alert to create]
-
-Each alert type provides its own way of defining the conditions to detect, but an expression formed by a series of clauses is a common pattern. Each clause has a UI control that allows you to define the clause. For example, in an index threshold alert the `WHEN` clause allows you to select an aggregation operation to apply to a numeric field.
-
-[role="screenshot"]
-image::images/alert-flyout-alert-conditions.png[UI for defining alert conditions on an index threshold alert]
-
-[float]
-[[defining-alerts-actions-details]]
-=== Action type and action details
-
-To add an action to an alert, you first select the type of action:
-
-[role="screenshot"]
-image::images/alert-flyout-action-type-selection.png[UI for selecting an action type]
-
-When an alert instance matches a condition, the alert is marked as _Active_ and assigned an action group.  The actions in that group are triggered.
-When the condition is no longer detected, the alert is assigned to the _Recovered_ action group, which triggers any actions assigned to that group.
-
-**Run When** allows you to assign an action to an action group. This will trigger the action in accordance with your **Notify** setting.
-
-Each action must specify a <<alerting-concepts-connectors, connector>> instance. If no connectors exist for that action type, click *Add action* to create one.
-
-Each action type exposes different properties. For example an email action allows you to set the recipients, the subject, and a message body in markdown format. See <<action-types>> for details on the types of actions provided by {kib} and their properties.
-
-[role="screenshot"]
-image::images/alert-flyout-action-details.png[UI for defining an email action]
-
-[float]
-[[defining-alerts-actions-variables]]
-==== Action variables
-Using the https://mustache.github.io/[Mustache] template syntax `{{variable name}}`, you can pass alert values at the time a condition is detected to an action. You can access the list of available variables using the "add variable" button. Although available variables differ by alert type, all alert types pass the following variables:
-
-`alertId`:: The ID of the alert.
-`alertName`:: The name of the alert.
-`spaceId`:: The ID of the space for the alert.
-`tags`:: The list of tags applied to the alert.
-`date`:: The date the alert scheduled the action, in ISO format.
-`alertInstanceId`:: The ID of the alert instance that scheduled the action.
-`alertActionGroup`:: The ID of the action group of the alert instance that scheduled the action.
-`alertActionSubgroup`:: The action subgroup of the alert instance that scheduled the action.
-`alertActionGroupName`:: The name of the action group of the alert instance that scheduled the action.
-`kibanaBaseUrl`:: The configured <<server-publicBaseUrl, `server.publicBaseUrl`>>. If not configured, this will be empty.
-
-[role="screenshot"]
-image::images/alert-flyout-action-variables.png[Passing alert values to an action]
-
-Some cases exist where the variable values will be "escaped", when used in a context where escaping is needed:
-
-- For the <<email-action-type, Email>> connector, the `message` action configuration property escapes any characters that would be interpreted as Markdown.
-- For the <<slack-action-type, Slack>> connector, the `message` action configuration property escapes any characters that would be interpreted as Slack Markdown.
-- For the <<webhook-action-type, Webhook>> connector, the `body` action configuration property escapes any characters that are invalid in JSON string values.
-
-Mustache also supports "triple braces" of the form `{{{variable name}}}`, which indicates no escaping should be done at all.  Care should be used when using this form, as it could end up rendering the variable content in such a way as to make the resulting parameter invalid or formatted incorrectly.
-
-Each alert type defines additional variables as properties of the variable `context`.  For example, if an alert type defines a variable `value`, it can be used in an action parameter as `{{context.value}}`.  
-
-For diagnostic or exploratory purposes, action variables whose values are objects, such as `context`, can be referenced directly as variables.  The resulting value will be a JSON representation of the object.  For example, if an action parameter includes `{{context}}`, it will expand to the JSON representation of all the variables and values provided by the alert type.
-
-You can attach more than one action. Clicking the "Add action" button will prompt you to select another alert type and repeat the above steps again.
-
-[role="screenshot"]
-image::images/alert-flyout-add-action.png[You can add multiple actions on an alert]
-
-[NOTE]
-==============================================
-Actions are not required on alerts. You can run an alert without actions to understand its behavior, and then <<action-settings, configure actions>> later.
-==============================================
-
-[float]
-=== Manage alerts
-
-To modify an alert after it was created, including muting or disabling it, use the <<alert-management, alert listing in the Management UI>>.

docs/user/alerting/defining-rules.asciidoc

@@ -0,0 +1,115 @@
+[role="xpack"]
+[[defining-alerts]]
+== Defining rules
+
+{kib} alerting rules can be created in a variety of apps including <<xpack-apm,*APM*>>, <<xpack-ml,*{ml-app}*>>, <<metrics-app,*Metrics*>>, <<xpack-siem,*Security*>>, <<uptime-app,*Uptime*>> and from the <<management,*Management*>> UI. While alerting details may differ from app to app, they share a common interface for defining and configuring rules that this section describes in more detail.
+
+[float]
+=== Create a rule
+
+When you create a rule, you must define the rule details, conditions, and actions.
+
+. <<defining-alerts-general-details, General rule details>>
+. <<defining-alerts-type-conditions, Rule type and conditions>>
+. <<defining-alerts-actions-details, Action type and action details>>
+
+image::images/rule-flyout-sections.png[The three sections of a rule definition]
+
+[float]
+[[defining-alerts-general-details]]
+=== General rule details
+
+All rules share the following four properties.
+
+[role="screenshot"]
+image::images/rule-flyout-general-details.png[alt='All rules have name, tags, check every, and notify properties in common']
+
+Name::      The name of the rule. While this name does not have to be unique, the name can be referenced in actions and also appears in the searchable rule listing in the management UI. A distinctive name can help identify and find a rule.
+Tags::      A list of tag names that can be applied to a rule. Tags can help you organize and find rules, because tags appear in the rule listing in the management UI which is searchable by tag.
+Check every::      This value determines how frequently the rule conditions below are checked. Note that the timing of background rule checks are not guaranteed, particularly for intervals of less than 10 seconds. See <<alerting-production-considerations, Alerting production considerations>> for more information.
+Notify::      This value limits how often actions are repeated when an alert remains active across rule checks. See <<alerting-concepts-suppressing-duplicate-notifications>> for more information. +
+- **Only on status change**: Actions are not repeated when an alert remains active across checks. Actions run only when the rule status changes.
+- **Every time rule is active**: Actions are repeated when an alert remains active across checks.
+- **On a custom action interval**: Actions are suppressed for the throttle interval, but repeat when an alert remains active across checks for a duration longer than the throttle interval.
+
+
+[float]
+[[defining-alerts-type-conditions]]
+=== Rule type and conditions
+
+Depending upon the {kib} app and context, you may be prompted to choose the type of rule you wish to create. Some apps will pre-select the type of rule for you.
+
+[role="screenshot"]
+image::images/rule-flyout-rule-type-selection.png[Choosing the type of rule to create]
+
+Each rule type provides its own way of defining the conditions to detect, but an expression formed by a series of clauses is a common pattern. Each clause has a UI control that allows you to define the clause. For example, in an index threshold rule the `WHEN` clause allows you to select an aggregation operation to apply to a numeric field.
+
+[role="screenshot"]
+image::images/rule-flyout-rule-conditions.png[UI for defining rule conditions on an index threshold rule]
+
+[float]
+[[defining-alerts-actions-details]]
+=== Action type and action details
+
+To add an action to a rule, you first select the type of connector:
+
+[role="screenshot"]
+image::images/rule-flyout-connector-type-selection.png[UI for selecting an action type]
+
+When an alert matches a condition, the rule is marked as _Active_ and assigned an action group. The actions in that group are triggered.
+When the condition is no longer detected, the rule is assigned to the _Recovered_ action group, which triggers any actions assigned to that group.
+
+**Run When** allows you to assign an action to an action group. This will trigger the action in accordance with your **Notify** setting.
+
+Each action must specify a <<alerting-concepts-connectors, connector>> instance. If no connectors exist for that action type, click *Add connector* to create one.
+
+Each action type exposes different properties. For example an email action allows you to set the recipients, the subject, and a message body in markdown format. See <<action-types>> for details on the types of actions provided by {kib} and their properties.
+
+[role="screenshot"]
+image::images/rule-flyout-action-details.png[UI for defining an email action]
+
+[float]
+[[defining-alerts-actions-variables]]
+==== Action variables
+Using the https://mustache.github.io/[Mustache] template syntax `{{variable name}}`, you can pass rule values at the time a condition is detected to an action. You can access the list of available variables using the "add variable" button. Although available variables differ by rule type, all rule types pass the following variables:
+
+`rule.id`:: The ID of the rule.
+`rule.name`:: The name of the rule.
+`rule.spaceId`:: The ID of the space for the rule.
+`rule.tags`:: The list of tags applied to the rule.
+`date`:: The date the rule scheduled the action, in ISO format.
+`alert.id`:: The ID of the alert that scheduled the action.
+`alert.actionGroup`:: The ID of the action group of the alert that scheduled the action.
+`alert.actionSubgroup`:: The action subgroup of the alert that scheduled the action.
+`alert.actionGroupName`:: The name of the action group of the alert that scheduled the action.
+`kibanaBaseUrl`:: The configured <<server-publicBaseUrl, `server.publicBaseUrl`>>. If not configured, this will be empty.
+
+[role="screenshot"]
+image::images/rule-flyout-action-variables.png[Passing rule values to an action]
+
+Some cases exist where the variable values will be "escaped", when used in a context where escaping is needed:
+
+- For the <<email-action-type, Email>> connector, the `message` action configuration property escapes any characters that would be interpreted as Markdown.
+- For the <<slack-action-type, Slack>> connector, the `message` action configuration property escapes any characters that would be interpreted as Slack Markdown.
+- For the <<webhook-action-type, Webhook>> connector, the `body` action configuration property escapes any characters that are invalid in JSON string values.
+
+Mustache also supports "triple braces" of the form `{{{variable name}}}`, which indicates no escaping should be done at all.  Care should be used when using this form, as it could end up rendering the variable content in such a way as to make the resulting parameter invalid or formatted incorrectly.
+
+Each rule type defines additional variables as properties of the variable `context`.  For example, if a rule type defines a variable `value`, it can be used in an action parameter as `{{context.value}}`.  
+
+For diagnostic or exploratory purposes, action variables whose values are objects, such as `context`, can be referenced directly as variables.  The resulting value will be a JSON representation of the object.  For example, if an action parameter includes `{{context}}`, it will expand to the JSON representation of all the variables and values provided by the rule type.
+
+You can attach more than one action. Clicking the "Add action" button will prompt you to select another rule type and repeat the above steps again.
+
+[role="screenshot"]
+image::images/rule-flyout-add-action.png[You can add multiple actions on a rule]
+
+[NOTE]
+==============================================
+Actions are not required on rules. You can run a rule without actions to understand its behavior, and then <<action-settings, configure actions>> later.
+==============================================
+
+[float]
+=== Manage rules
+
+To modify a rule after it was created, including muting or disabling it, use the <<alert-management, rule listing in the Management UI>>.

docs/user/alerting/index.asciidoc

@@ -1,5 +1,5 @@
 include::alerting-getting-started.asciidoc[]
-include::defining-alerts.asciidoc[]
+include::defining-rules.asciidoc[]
 include::action-types.asciidoc[]
-include::alert-types.asciidoc[]
+include::rule-types.asciidoc[]
 include::alerting-troubleshooting.asciidoc[]

docs/user/alerting/map-rules/geo-rule-types.asciidoc

@@ -1,16 +1,16 @@
 [role="xpack"]
 [[geo-alerting]]
-=== Geo alerting
+=== Geo rule type
 
-Alerting now includes one additional stack alert: <<alert-type-tracking-containment>>.
+Alerting now includes one additional stack rule: <<rule-type-tracking-containment>>.
 
-As with other stack alerts, you need `all` access to the *Stack Alerts* feature
-to be able to create and edit a geo alert.
+As with other stack rules, you need `all` access to the *Stack Rules* feature
+to be able to create and edit a geo rule.
 See <<kibana-feature-privileges, feature privileges>> for more information on configuring roles that provide access to this feature. 
 
 [float]
 ==== Geo alerting requirements
-To create a *Tracking containment* alert, the following requirements must be present:
+To create a *Tracking containment* rule, the following requirements must be present:
 
 - *Tracks index or index pattern*: An index containing a `geo_point` field, `date` field,
 and some form of entity identifier. An entity identifier is a `keyword` or `number`
@@ -18,7 +18,7 @@ field that consistently identifies the entity to be tracked. The data in this in
 updating so that there are entity movements to alert upon.
 - *Boundaries index or index pattern*: An index containing `geo_shape` data, such as boundary data and bounding box data.
 This data is presumed to be static (not updating). Shape data matching the query is
-harvested once when the alert is created and anytime after when the alert is re-enabled
+harvested once when the rule is created and anytime after when the rule is re-enabled
 after disablement.
 
 By design, current interval entity locations (_current_ is determined by `date` in
@@ -26,26 +26,26 @@ the *Tracked index or index pattern*) are queried to determine if they are conta
 within any monitored boundaries. Entity
 data should be somewhat "real time", meaning the dates of new documents aren’t older
 than the current time minus the amount of the interval. If data older than
-`now - <current interval>` is ingested, it won't trigger an alert.
+`now - <current interval>` is ingested, it won't trigger a rule.
 
 [float]
-==== Creating a geo alert
-Click the *Create* button in the <<alert-management, alert management UI>>.
-Complete the <<defining-alerts-general-details, general alert details>>.
+==== Creating a geo rule
+Click the *Create* button in the <<alert-management, rule management UI>>.
+Complete the <<defining-alerts-general-details, general rule details>>.
 
 [role="screenshot"]
-image::user/alerting/images/alert-types-tracking-select.png[Choosing a tracking alert type]
+image::user/alerting/images/alert-types-tracking-select.png[Choosing a tracking rule type]
 
 [float]
-[[alert-type-tracking-containment]]
+[[rule-type-tracking-containment]]
 ==== Tracking containment
-The Tracking containment alert type runs an {es} query over indices, determining if any
+The Tracking containment rule type runs an {es} query over indices, determining if any
 documents are currently contained within any boundaries from the specified boundary index.
 In the event that an entity is contained within a boundary, an alert may be generated.
 
 [float]
 ===== Defining the conditions
-Tracking containment alerts have 3 clauses that define the condition to detect,
+Tracking containment rules have 3 clauses that define the condition to detect,
 as well as 2 Kuery bars used to provide additional filtering context for each of the indices.
 
 [role="screenshot"]
@@ -54,15 +54,15 @@ image::user/alerting/images/alert-types-tracking-containment-conditions.png[Five
 Index (entity):: This clause requires an *index or index pattern*, a *time field* that will be used for the *time window*, and a *`geo_point` field* for tracking.
 When entity:: This clause specifies which crossing option to track. The values
 *Entered*, *Exited*, and *Crossed* can be selected to indicate which crossing conditions
-should trigger an alert. *Entered* alerts on entry into a boundary, *Exited* alerts on exit
+should trigger a rule. *Entered* alerts on entry into a boundary, *Exited* alerts on exit
 from a boundary, and *Crossed* alerts on all boundary crossings whether they be entrances
 or exits.
 Index (Boundary):: This clause requires an *index or index pattern*, a *`geo_shape` field*
 identifying boundaries, and an optional *Human-readable boundary name* for better alerting
 messages.
 
-Conditions for how an alert is tracked can be specified uniquely for each individual action.
-An alert can be triggered either when a containment condition is met or when an entity
+Conditions for how a rule is tracked can be specified uniquely for each individual action.
+A rule can be triggered either when a containment condition is met or when an entity
 is no longer contained.
 
 [role="screenshot"]

docs/user/alerting/rule-types.asciidoc

@@ -0,0 +1,42 @@
+[role="xpack"]
+[[rule-types]]
+== Rules
+
+Kibana provides two types of rules:
+
+* Stack rules, which are built into {kib}
+* Domain-specific rules, which are registered by {kib} apps.
+
+[float]
+==== Standard stack rules
+
+{kib} provides two stack rules: 
+
+* <<rule-type-index-threshold>>
+* <<rule-type-es-query>>
+
+Users require the `all` privilege to access the *Stack Rules* feature and create and edit rules.
+See <<kibana-feature-privileges, feature privileges>> for more information.
+
+[float]
+==== Domain-specific rules
+
+For domain-specific rules, refer to the documentation for that app.
+{kib} supports these rules:
+
+* {observability-guide}/create-alerts.html[Observability rules]
+* {security-guide}/prebuilt-rules.html[Security rules]
+* <<geo-alerting, Maps rules>>
+* {ml-docs}/ml-configuring-alerts.html[{ml-cap} rules] beta:[]
+
+[NOTE]
+==============================================
+Some rule types are subscription features, while others are free features.
+For a comparison of the Elastic subscription levels,
+see {subscriptions}[the subscription page].
+==============================================
+
+
+include::stack-rules/index-threshold.asciidoc[]
+include::stack-rules/es-query.asciidoc[]
+include::map-rules/geo-rule-types.asciidoc[]

docs/user/alerting/stack-rules/es-query.asciidoc

@@ -1,13 +1,13 @@
 [role="xpack"]
-[[alert-type-es-query]]
+[[rule-type-es-query]]
 === {es} query
 
-The {es} query alert type runs a user-configured {es} query, compares the number of matches to a configured threshold, and schedules actions to run when the threshold condition is met.
+The {es} query rule type runs a user-configured {es} query, compares the number of matches to a configured threshold, and schedules actions to run when the threshold condition is met.
 
 [float]
-==== Create the alert
+==== Create the rule
 
-Fill in the <<defining-alerts-general-details, alert details>>, then select *{es} query*.
+Fill in the <<defining-alerts-general-details, rule details>>, then select *{es} query*.
 
 [float]
 ==== Define the conditions
@@ -15,35 +15,35 @@ Fill in the <<defining-alerts-general-details, alert details>>, then select *{es
 Define properties to detect the condition.
 
 [role="screenshot"]
-image::user/alerting/images/alert-types-es-query-conditions.png[Five clauses define the condition to detect]
+image::user/alerting/images/rule-types-es-query-conditions.png[Five clauses define the condition to detect]
 
 Index:: This clause requires an *index or index pattern* and a *time field* that will be used for the *time window*.
 Size:: This clause specifies the number of documents to pass to the configured actions when the the threshold condition is met.
 {es} query:: This clause specifies the ES DSL query to execute. The number of documents that match this query will be evaulated against the threshold
 condition. Aggregations are not supported at this time. 
 Threshold:: This clause defines a threshold value and a comparison operator  (`is above`, `is above or equals`, `is below`, `is below or equals`, or `is between`). The number of documents that match the specified query is compared to this threshold.
-Time window:: This clause determines how far back to search for documents, using the *time field* set in the *index* clause. Generally this value should be set to a value higher than the *check every* value in the <<defining-alerts-general-details, general alert details>>, to avoid gaps in detection. 
+Time window:: This clause determines how far back to search for documents, using the *time field* set in the *index* clause. Generally this value should be set to a value higher than the *check every* value in the <<defining-alerts-general-details, general rule details>>, to avoid gaps in detection. 
 
 [float]
 ==== Add action variables
 
-<<defining-alerts-actions-details, Add an action>> to run when the alert condition is met. The following variables are specific to the {es} query alert. You can also specify <<defining-alerts-actions-variables, variables common to all alerts>>.
+<<defining-alerts-actions-details, Add an action>> to run when the rule condition is met. The following variables are specific to the {es} query rule. You can also specify <<defining-alerts-actions-variables, variables common to all rules>>.
 
-`context.title`:: A preconstructed title for the alert. Example: `alert term match alert query matched`.
-`context.message`:: A preconstructed message for the alert. Example: +
-`alert 'term match alert' is active:` +
+`context.title`:: A preconstructed title for the rule. Example: `rule term match alert query matched`.
+`context.message`:: A preconstructed message for the rule. Example: +
+`rule 'term match alert' is active:` +
 `- Value: 42` +
 `- Conditions Met: count greater than 4 over 5m` +
 `- Timestamp: 2020-01-01T00:00:00.000Z`
 
 `context.group`:: The name of the action group associated with the condition. Example: `query matched`.
-`context.date`:: The date, in ISO format, that the alert met the condition. Example: `2020-01-01T00:00:00.000Z`.
-`context.value`:: The value of the alert that met the condition.
+`context.date`:: The date, in ISO format, that the rule met the condition. Example: `2020-01-01T00:00:00.000Z`.
+`context.value`:: The value of the rule that met the condition.
 `context.conditions`:: A description of the condition. Example: `count greater than 4`.
 `context.hits`:: The most recent ES documents that matched the query. Using the https://mustache.github.io/[Mustache] template array syntax, you can iterate over these hits to get values from the ES documents into your actions.
 +
 [role="screenshot"]
-image::images/alert-types-es-query-example-action-variable.png[Iterate over hits using Mustache template syntax]
+image::images/rule-types-es-query-example-action-variable.png[Iterate over hits using Mustache template syntax]
 
 
 [float]
@@ -55,9 +55,9 @@ Use the *Test query* feature to verify that your query DSL is valid.
 match the query will be displayed.
 +
 [role="screenshot"]
-image::user/alerting/images/alert-types-es-query-valid.png[Test {es} query returns number of matches when valid]
+image::user/alerting/images/rule-types-es-query-valid.png[Test {es} query returns number of matches when valid]
 
 * An error message is shown if the query is invalid.
 +
 [role="screenshot"]
-image::user/alerting/images/alert-types-es-query-invalid.png[Test {es} query shows error when invalid]
+image::user/alerting/images/rule-types-es-query-invalid.png[Test {es} query shows error when invalid]