[DOCS] Add description for untracked alert status

docs/user/alerting/create-and-manage-rules.asciidoc

@@ -100,7 +100,7 @@ For example, you can have actions that create an {opsgenie} alert when rule cond
 [[alerting-concepts-suppressing-duplicate-notifications]]
 [TIP]
 ==============================================
-If you are not using alert summaries, actions are triggered per alert and 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, and the action frequency is `On check intervals`:
+If you are not using alert summaries, actions are generated per alert and 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, and the action frequency is `On check intervals`:
 
 * Minute 1: server X123 > 0.9. _One email_ is sent for server X123.
 * Minute 2: X123 and Y456 > 0.9. _Two emails_ are sent, one for X123 and one for Y456.
@@ -134,44 +134,25 @@ For more information about common action variables, refer to <<rule-action-varia
 [[controlling-rules]]
 === Snooze and disable rules
 
-The rule listing enables you to quickly snooze, disable, enable, or delete
-individual rules. For example, you can change the state of a rule:
+The rule listing enables you to quickly snooze, disable, enable, or delete individual rules.
+For example, you can change the state of a rule:
 
 [role="screenshot"]
 image:images/individual-enable-disable.png[Use the rule status dropdown to enable or disable an individual rule]
 // NOTE: This is an autogenerated screenshot. Do not edit it directly.
 
-When you snooze a rule, the rule checks continue to run on a schedule but the
-alert will not trigger any actions. You can snooze for a specified period of
-time, indefinitely, or schedule single or recurring downtimes:
+If there are rules that are not currently needed, disable them to stop running checks and reduce the load on your cluster.
+
+When you snooze a rule, the rule checks continue to run on a schedule but alerts will not generate actions.
+You can snooze for a specified period of time, indefinitely, or schedule single or recurring downtimes:
 
 [role="screenshot"]
 image:images/snooze-panel.png[Snooze notifications for a rule]
 // NOTE: This is an autogenerated screenshot. Do not edit it directly.
 
-When a rule is in a snoozed state, you can cancel or change the duration of
-this state.
-
-preview:[] To temporarily suppress notifications for _all_ rules, create a <<maintenance-windows,maintenance window>>.
-
-[float]
-[[importing-and-exporting-rules]]
-=== Import and export rules
-
-To import and export rules, use <<managing-saved-objects,Saved Objects>>.
-
-[NOTE]
-==============================================
-Some rule types cannot be exported through this interface:
-
-**Security rules** can be imported and exported using the {security-guide}/rules-ui-management.html#import-export-rules-ui[Security UI].
-
-**Stack monitoring rules** are <<kibana-alerts, automatically created>> for you and therefore cannot be managed in *Saved Objects*.
-==============================================
+When a rule is in a snoozed state, you can cancel or change the duration of this state.
 
-Rules are disabled on export. You are prompted to re-enable the rule on successful import.
-[role="screenshot"]
-image::images/rules-imported-banner.png[Rules import banner,500]
+preview:[] To temporarily suppress notifications for rules, you can also create a <<maintenance-windows,maintenance window>>.
 
 [float]
 [[rule-details]]
@@ -192,14 +173,19 @@ image::images/rule-details-alerts-active.png[Rule details page with multiple ale
 
 In this example, the rule detects when a site serves more than a threshold number of bytes in a 24 hour period. Four 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. Alerts come and go from the list depending on whether the rule conditions are met.
 
-When an alert is created, it generates actions. If the conditions that caused the alert persist, the actions run again according to the rule notification settings. There are three common alert statuses:
+When an alert is created, it generates actions. If the conditions that caused the alert persist, the actions run again according to the rule notification settings. There are four common alert statuses:
 
 `active`:: The conditions for the rule are met and actions should be generated according to the notification settings.
 `flapping`:: The alert is switching repeatedly between active and recovered states.
 `recovered`:: The conditions for the rule are no longer met and recovery actions should be generated.
+`untracked`:: Actions are no longer generated. For example, you can choose to move active alerts to this state when you disable or delete rules.
 
 NOTE: The `flapping` state is possible only if you have enabled alert flapping detection in *{stack-manage-app}* > *{rules-ui}* > *Settings*. For each space, you can choose a look back window and threshold that are used to determine whether alerts are flapping. For example, you can specify that the alert must change status at least 6 times in the last 10 runs. If the rule has actions that run when the alert status changes, those actions are suppressed while the alert is flapping.
 
+You can mute an alert to temporarily suppress future actions.
+Open the action menu (…) for the appropriate alert in the table and select *Mute*.
+To permanently suppress actions for an alert, open the actions menu and select *Mark as untracked*.
+
 If there are rule actions that failed to run successfully, you can see the details on the *History* tab.
 In the *Message* column, click the warning or expand icon image:images/expand-icon-2.png[double arrow icon to open a flyout with the document details] or click the number in the *Errored actions* column to open the *Errored Actions* panel.
 In this example, the action failed because the <<action-config-email-domain-allowlist,`xpack.actions.email.domain_allowlist`>> setting was updated and the action's email recipient is no longer included in the allowlist:
@@ -211,8 +197,21 @@ image::images/rule-details-errored-actions.png[Rule histor page with alerts that
 If an alert was affected by a maintenance window, its identifier appears in the *Maintenance windows* column.
 For more information about their impact on alert notifications, refer to <<maintenance-windows>>.
 
-You can suppress future actions for a specific alert by turning on the *Mute* toggle. If a muted alert no longer meets the rule conditions, it stays in the list to avoid generating actions if the conditions recur. You can also disable a rule, which stops it from running checks and clears any alerts it was tracking. You may want to disable rules that are not currently needed to reduce the load on {kib} and {es}.
+[float]
+[[importing-and-exporting-rules]]
+=== Import and export rules
+
+To import and export rules, use <<managing-saved-objects,saved objects>>.
+
+[NOTE]
+==============================================
+Some rule types cannot be exported through this interface:
+
+**Security rules** can be imported and exported using the {security-guide}/rules-ui-management.html#import-export-rules-ui[Security UI].
+
+**Stack monitoring rules** are <<kibana-alerts,automatically created>> for you and therefore cannot be managed in *Saved Objects*.
+==============================================
 
+Rules are disabled on export. You are prompted to re-enable the rule on successful import.
 [role="screenshot"]
-image::images/rule-details-disabling.png[Use the disable toggle to turn off rule checks and clear alerts tracked]
-// NOTE: This is an autogenerated screenshot. Do not edit it directly.
+image::images/rules-imported-banner.png[Rules import banner,500]

x-pack/test/screenshot_creation/apps/response_ops_docs/stack_alerting/list_view.ts

@@ -57,14 +57,6 @@ export default function ({ getService, getPageObjects }: FtrProviderContext) {
         1400,
         1024
       );
-      const actionsButton = await testSubjects.find('ruleActionsButton');
-      await actionsButton.click();
-      await commonScreenshots.takeScreenshot(
-        'rule-details-disabling',
-        screenshotDirectories,
-        1400,
-        1024
-      );
     });
   });
 }