[DOCS] Add alerting known issue (elastic#153905)

docs/CHANGELOG.asciidoc

@@ -60,6 +60,12 @@ There are no breaking changes in {kib} 8.6.2.
 
 {kibana-ref-all}/8.5/release-notes-8.5.0.html#breaking-changes-8.5.0[8.5.0] | {kibana-ref-all}/8.4/release-notes-8.4.0.html#breaking-changes-8.4.0[8.4.0] | {kibana-ref-all}/8.3/release-notes-8.3.0.html#breaking-changes-8.3.0[8.3.0] | {kibana-ref-all}/8.2/release-notes-8.2.0.html#breaking-changes-8.2.0[8.2.0] | {kibana-ref-all}/8.1/release-notes-8.1.0.html#breaking-changes-8.1.0[8.1.0] | {kibana-ref-all}/8.0/release-notes-8.0.0.html#breaking-changes-8.0.0[8.0.0] | {kibana-ref-all}/8.0/release-notes-8.0.0-rc2.html#breaking-changes-8.0.0-rc2[8.0.0-rc2] | {kibana-ref-all}/8.0/release-notes-8.0.0-rc1.html#breaking-changes-8.0.0-rc1[8.0.0-rc1] | {kibana-ref-all}/8.0/release-notes-8.0.0-beta1.html#breaking-changes-8.0.0-beta1[8.0.0-beta1] | {kibana-ref-all}/8.0/release-notes-8.0.0-alpha2.html#breaking-changes-8.0.0-alpha2[8.0.0-alpha2] | {kibana-ref-all}/8.0/release-notes-8.0.0-alpha1.html#breaking-changes-8.0.0-alpha1[8.0.0-alpha1]
 
+[float]
+[[known-issues-8.6.2]]
+=== Known issues
+
+include::CHANGELOG.asciidoc[tag=known-issue-153175]
+
 [float]
 [[enhancement-v8.6.2]]
 === Enhancements
@@ -106,6 +112,12 @@ Omit or include `ssl` keys when appropriate for project monitors and private loc
 
 Review the following information about the {kib} 8.6.1 release.
 
+[float]
+[[known-issues-8.6.1]]
+=== Known issues
+
+include::CHANGELOG.asciidoc[tag=known-issue-153175]
+
 [float]
 [[breaking-changes-8.6.1]]
 === Breaking changes
@@ -180,13 +192,27 @@ Review the following information about the {kib} 8.6.0 release.
 [[known-issues-8.6.0]]
 === Known issues
 
+// tag::known-issue-153175[]
+[discrete]
+.Unable to load *{stack-manage-app}* > *{rules-ui}* due to corrupted rule definitions
+[%collapsible]
+====
+*Details* +
+Releases 8.5 and 8.6 have a bug that corrupts rules when you update API keys or manage snooze schedules. In particular, it affects tracking containment rules and {es} query rules with KQL or Lucene query types. Releases 8.7 and beyond do not include this bug (fixed in {kibana-pull}153370[#153370]).
+
+*Impact* +
+This known issue causes "unable to load rules" messages to occur in *{stack-manage-app}* > *{rules-ui}*. To temporarily work around the problem, copy the rule content (params, name, tags, actions) for the problematic rules, delete the rules, then recreate them. For more details, refer to <<rule-type-es-query-issues,{es} query rules>> and <<geo-alerting-issues,Tracking containment rules>>.
+====
+// end::known-issue-153175[]
+
 [discrete]
 [[known-issue-146020]]
 .Attempting to create APM latency threshold rules from the Observability rules page fail
 [%collapsible]
 ====
 *Details* +
 When you attempt to create an APM latency threshold rule in **Observability** > **Alerts** > **Rules** for all services or all transaction types, the request will fail with a `params invalid` error.
+
 *Impact* +
 This known issue only impacts the Observability Rules page. To work around this issue, create APM latency threshold rules in the APM Alerts and Rules dialog. See {kibana-ref}/apm-alerts.html[Alerts and rules] for detailed instructions.
 ====
@@ -199,6 +225,7 @@ This known issue only impacts the Observability Rules page. To work around this
 When you upgrade to 8.6.0, progress bars on existing *Lens* metric visualizations are hidden.
 
 To display progress bars in existing *Lens* metric visualizations:
+
 . Open the main menu, then click *Visualize Library*.
 . From the *Visualize Library* list, click the metric visualization. 
 . In *Lens*, click the *Primary metric* field in the layer pane.

docs/user/alerting/rule-types/es-query.asciidoc

@@ -154,4 +154,11 @@ window of 1 hour and checks if there are more than 99 matches for the query. The
 | `Run 4 (0:03)`
 | Rule finds 190 matches in the last hour. 71 of them are duplicates that were already alerted on previously, so you actually have 119 matches: `119 > 99`
 | Rule is active and user is alerted.
-|===
+|===
+
+
+[float]
+[[rule-type-es-query-issues]]
+=== Known issues
+
+include::geo-rule-types.asciidoc[tag=known-issue-load-rules]

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

@@ -1,14 +1,13 @@
-[role="xpack"]
 [[geo-alerting]]
 === Tracking containment
 
-<<maps, Maps>> offers the Tracking containment rule type which runs an {es} query over indices to determine whether any
+<<maps,Maps>> offers the tracking containment rule type which runs an {es} query over indices to determine whether 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]
 ==== Requirements
-To create a Tracking containment rule, the following requirements must be present:
+To create a tracking containment rule, the following requirements must be present:
 
 - *Tracks index or data view*: An index containing a `geo_point` field, `date` field,
 and some form of entity identifier. An entity identifier is a `keyword` or `number`
@@ -58,3 +57,60 @@ is no longer contained.
 
 [role="screenshot"]
 image::user/alerting/images/alert-types-tracking-containment-action-options.png[Five clauses define the condition to detect]
+
+[float]
+[[geo-alerting-issues]]
+==== Known issues
+
+// The following content is reused in other rule types
+// tag::known-issue-load-rules[]
+There is a known issue in 8.5 and 8.6 that results in corruption of the rule definition when you update API keys or add or remove snooze schedules in *{stack-manage-app}* > *{rules-ui}*. 
+In particular, this bug affects {es} query rules with the KQL or Lucene query type and tracking containment rules.
+As a result of this bug, an "Unable to load rules" error occurs in *{rules-ui}*.
+
+The long-term solution is to migrate to the latest release; 8.7 and later releases contain the fix for this bug.
+If you encounter this bug in {minor-version}, you can recover access to your rules in {kib} by using APIs to delete and recreate them:
+
+. Find the affected rules. For example, run the following query in *{dev-tools-app}*:
++
+--
+[source,console]
+----
+GET .kibana*/_search
+{
+  "query": {
+    "bool": {
+      "filter": [
+        {
+          "terms": {
+            "alert.alertTypeId": [
+              ".es-query",
+              ".geo-containment"
+            ]
+          }
+        }
+      ],
+      "must_not": {
+        "exists": {
+          "field": "references"
+        }
+      }
+    }
+  }
+}
+----
+--
+. Make a copy of the query output, since you will use it to recreate the rules.
+. Delete the affected rules. For example, run the following query in *{dev-tools-app}*, replacing `<rule_id>` with the appropriate rule identifiers:
++
+--
+[source,console]
+----
+DELETE kbn:/api/alerting/rule/<rule_id>
+----
+--
+. Recreate the rules. For example, use *{stack-manage-app}* > *{rules-ui}* or the <<create-rule-api,create rule API>> with the property values obtained from your query output.
+
+NOTE: If you update the API keys or add or remove snooze schedules again, the problem will re-occur until you upgrade to a release that contains the fix.
+
+// end::known-issue-load-rules[]