diff --git a/docs/user/alerting/alerting-setup.asciidoc b/docs/user/alerting/alerting-setup.asciidoc
index 6643f8d0ec870..9e3fb54e39444 100644
--- a/docs/user/alerting/alerting-setup.asciidoc
+++ b/docs/user/alerting/alerting-setup.asciidoc
@@ -5,35 +5,47 @@
Set up
++++
-Alerting is automatically enabled in {kib}, but might require some additional configuration.
+Alerting is automatically enabled in {kib}, but might require some additional
+configuration.
[float]
[[alerting-prerequisites]]
=== Prerequisites
If you are using an *on-premises* Elastic Stack deployment:
-* In the kibana.yml configuration file, add the <> setting.
-* For emails to have a footer with a link back to {kib}, set the <> configuration setting.
+* In the kibana.yml configuration file, add the
+<>
+setting.
+* For emails to have a footer with a link back to {kib}, set the
+<> configuration setting.
-If you are using an *on-premises* Elastic Stack deployment with <>:
+If you are using an *on-premises* Elastic Stack deployment with
+<>:
-* If you are unable to access {kib} Alerting, ensure that you have not {ref}/security-settings.html#api-key-service-settings[explicitly disabled API keys].
+* If you are unable to access {kib} Alerting, ensure that you have not
+{ref}/security-settings.html#api-key-service-settings[explicitly disabled API keys].
-The alerting framework uses queries that require the `search.allow_expensive_queries` setting to be `true`. See the scripts {ref}/query-dsl-script-query.html#_allow_expensive_queries_4[documentation].
+The alerting framework uses queries that require the
+`search.allow_expensive_queries` setting to be `true`. See the scripts
+{ref}/query-dsl-script-query.html#_allow_expensive_queries_4[documentation].
[float]
[[alerting-setup-production]]
=== Production considerations and scaling guidance
-When relying on alerting and actions as mission critical services, make sure you follow the <>.
+When relying on alerting and actions as mission critical services, make sure you
+follow the
+<>.
-See <> for more information on the scalability of Alerting.
+See <> for more information on the scalability of
+Alerting.
[float]
[[alerting-security]]
=== Security
-To access alerting in a space, a user must have access to one of the following features:
+To access alerting in a space, a user must have access to one of the following
+features:
* Alerting
* <>
@@ -43,31 +55,53 @@ To access alerting in a space, a user must have access to one of the following f
* <>
* <>
-See <> 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 a rule or to edit a rule that has an action attached to it.
+See <> 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 a rule or to edit a rule
+that has an action attached to it.
[float]
[[alerting-restricting-actions]]
==== Restrict actions
-For security reasons you may wish to limit the extent to which {kib} can connect to external services. <> allows you to disable certain <> 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. <> allows you to disable certain
+<> and allowlist the hostnames that {kib} can connect with.
[float]
[[alerting-spaces]]
=== Space isolation
-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.
+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
-Rules are authorized using an <> associated with the last user to edit the rule. This API key captures a snapshot of the user's privileges at the time of edit and is subsequently used to run all background tasks associated with the rule, including condition checks like {es} queries and triggered actions. The following rule actions will re-generate the API key:
+Rules are authorized using an <> associated with the last user
+to edit the rule. This API key captures a snapshot of the user's privileges at
+the time of the edit. They are subsequently used to run all background tasks
+associated with the rule, including condition checks like {es} queries and
+triggered actions. The following rule actions will re-generate the API key:
* Creating a rule
* Updating a rule
+When you disable a rule, it retains the associated API key which is re-used when
+the rule is enabled. If the API key is missing when you enable the rule (for
+example, in the case of imported rules), it generates a new key that has your
+security privileges.
+
+You can update an API key manually in
+**{stack-manage-app} > {rules-ui}** or in the rule details page by selecting
+**Update API key** in the actions menu.
+
[IMPORTANT]
==============================================
-If a rule requires certain privileges, such as index privileges, to run, and a user without those privileges updates the rule, the rule will no longer function. Conversely, if a user with greater or administrator privileges modifies the rule, it will begin running with increased privileges.
+If a rule requires certain privileges, such as index privileges, to run, and a
+user without those privileges updates the rule, the rule will no longer
+function. Conversely, if a user with greater or administrator privileges
+modifies the rule, it will begin running with increased privileges.
==============================================