Merge branch 'main' into issue-5878-visualise-tab

Author: nastasha-solomon

docs/detections/alert-suppression.asciidoc

@@ -8,7 +8,7 @@
 
 * {ml-cap} rules have <<ml-requirements,additional requirements>> for alert suppression.
 
-preview::["Alert suppression is in technical preview for threshold, indicator match, event correlation, and new terms rules. The functionality may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features."]
+preview::["Alert suppression is in technical preview for event correlation rules. The functionality may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features."]
 --
 
 Alert suppression allows you to reduce the number of repeated or duplicate detection alerts created by these detection rule types:

docs/detections/api/rules/rules-api-create.asciidoc

@@ -511,7 +511,7 @@ a detection rule exception (`detection`) or an endpoint exception (`endpoint`).
 [[opt-fields-alert-suppression-create]]
 ===== Optional alert suppression fields for query, indicator match, threshold, event correlation (non-sequence queries only), new terms, {esql}, and {ml} rules
 
-preview::["Alert suppression is in technical preview for threshold, indicator match, event correlation, new terms, {ml}, and {esql} rules. The functionality may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features."]
+preview::["Alert suppression is in technical preview for event correlation rules. The functionality may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features."]
 
 ====== Query, indicator match, event correlation (non-sequence queries only), new terms, {esql}, and {ml} rules
 

docs/detections/api/rules/rules-api-update.asciidoc

@@ -540,7 +540,7 @@ in the UI (*Rules* -> *Detection rules (SIEM)* -> *_Rule name_*).
 [[opt-fields-alert-suppression-update]]
 ===== Optional alert suppression fields for query, indicator match, threshold, event correlation (non-sequence queries only), new terms, {esql}, and {ml} rules
 
-preview::["Alert suppression is in technical preview for threshold, indicator match, event correlation, new terms, {ml}, and {esql} rules. The functionality may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features."]
+preview::["Alert suppression is in technical preview for event correlation rules. The functionality may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features."]
 
 ====== Query, indicator match, event correlation (non-sequence queries only), new terms, {esql}, and {ml} rules
 

docs/detections/rules-ui-create.asciidoc

@@ -50,7 +50,7 @@ then select:
 NOTE: If a required job isn't currently running, it will automatically start when you finish configuring and enable the rule.
 .. The anomaly score threshold above which alerts are created.
 +
-. preview:[] (Optional, https://www.elastic.co/pricing[Platinum or higher subscription] required) Use *Suppress alerts by* to reduce the number of repeated or duplicate alerts created by the rule. Refer to <<alert-suppression>> for more information.
+. (Optional, https://www.elastic.co/pricing[Platinum or higher subscription] required) Use *Suppress alerts by* to reduce the number of repeated or duplicate alerts created by the rule. Refer to <<alert-suppression>> for more information.
 +
 NOTE: Because {ml} rules generate alerts from anomalies, which don't contain source event fields, you can only use anomaly fields when configuring alert suppression.
 +
@@ -139,7 +139,7 @@ You can also leave the *Group by* field undefined. The rule then creates an aler
 +
 IMPORTANT: Alerts created by threshold rules are synthetic alerts that do not resemble the source documents. The alert itself only contains data about the fields that were aggregated over (the *Group by* fields). Other fields are omitted, because they can vary across all source documents that were counted toward the threshold. Additionally, you can reference the actual count of documents that exceeded the threshold from the `kibana.alert.threshold_result.count` field.
 
-. preview:[] (Optional, https://www.elastic.co/pricing[Platinum or higher subscription] required) Select *Suppress alerts* to reduce the number of repeated or duplicate alerts created by the rule. Refer to <<alert-suppression>> for more information.
+. (Optional, https://www.elastic.co/pricing[Platinum or higher subscription] required) Select *Suppress alerts* to reduce the number of repeated or duplicate alerts created by the rule. Refer to <<alert-suppression>> for more information.
 +
 
 ////
@@ -269,7 +269,7 @@ they can be selected here. When alerts generated by the rule are investigated
 in the Timeline, Timeline query values are replaced with their corresponding alert
 field values.
 +
-. preview:[] (Optional, https://www.elastic.co/pricing[Platinum or higher subscription] required) Select *Suppress alerts* to reduce the number of repeated or duplicate alerts created by the rule. Refer to <<alert-suppression>> for more information.
+. (Optional, https://www.elastic.co/pricing[Platinum or higher subscription] required) Select *Suppress alerts* to reduce the number of repeated or duplicate alerts created by the rule. Refer to <<alert-suppression>> for more information.
 +
 
 ////
@@ -328,7 +328,7 @@ IMPORTANT: When checking multiple fields, each unique combination of values from
 +
 For example, if a rule has an interval of 5 minutes, no additional look-back time, and a history window size of 7 days, a term will be considered new only if the time it appears within the last 7 days is also within the last 5 minutes. Configure the rule interval and additional look-back time when you <<rule-schedule, set the rule's schedule>>.
 
-. preview:[] (Optional, https://www.elastic.co/pricing[Platinum or higher subscription] required) Use *Suppress alerts by* to reduce the number of repeated or duplicate alerts created by the rule. Refer to <<alert-suppression>> for more information.
+. (Optional, https://www.elastic.co/pricing[Platinum or higher subscription] required) Use *Suppress alerts by* to reduce the number of repeated or duplicate alerts created by the rule. Refer to <<alert-suppression>> for more information.
 +
 
 ////
@@ -361,7 +361,7 @@ NOTE: Refer to the sections below to learn more about <<esql-rule-query-types,{e
 TIP: Click the help icon (image:images/esql-help-ref-button.png[Click the ES|QL help icon,20,20]) to open the in-product reference documentation for all {esql} commands and functions.
 +
 
-. preview:[] (Optional, https://www.elastic.co/pricing[Platinum or higher subscription] required) Use *Suppress alerts by* to reduce the number of repeated or duplicate alerts created by the rule. Refer to <<alert-suppression>> for more information.
+. (Optional, https://www.elastic.co/pricing[Platinum or higher subscription] required) Use *Suppress alerts by* to reduce the number of repeated or duplicate alerts created by the rule. Refer to <<alert-suppression>> for more information.
 +
 
 ////

docs/getting-started/advanced-setting.asciidoc

@@ -190,7 +190,7 @@ The `securitySolution:alertTags` field determines which options display in the a
 
 To ensure rules don't search cold and frozen data when executing, specify cold and frozen {ref}/data-tiers.html[data tiers] in the `excludedDataTiersForRuleExecution` field. Multiple data tiers must be separated by commas, for example: `data_frozen`, `data_cold`. This setting is turned off by default; turning it on can improve rule performance and reduce execution time. 
 
-This setting does not apply to {esql} or {ml} rules. 
+This setting does not apply to {ml} rules. 
 
 [TIP]
 ====

docs/reference/alert-schema.asciidoc

@@ -195,9 +195,15 @@ Type: string[]
 
 Shows the alert’s estimated timestamp, had the alert been created when the source event initially occurred. The value in this field is determined by the way the rule was run:
 
-* **Scheduled run**: Alerts created by scheduled runs have the same timestamp as the `kibana.alert.rule.execution.timestamp` field, which shows when the rule was executed.
+* **Scheduled run**: Alerts created by scheduled runs have the same timestamp as the `@timestamp` field, which shows when the alert was created.
 * **Manual run**: Alerts created by manual runs have a timestamp that falls within the time range specified for the manual run. For example, if you set a rule to manually run on event data from `10/01/2024 05:00 PM` to `10/07/2024 05:00 PM`, the `kibana.alert.intended_timestamp` value will be a date and time within that range.
 
 Type: date
 
+|N/A | `kibana.alert.rule.execution.type` a| 
+
+Shows if an alert was created by a manual run or a scheduled run. The value can be `manual` or `scheduled`.
+
+Type: keyword
+
 |==============================================

docs/serverless/alerts/alert-schema.mdx

@@ -891,7 +891,7 @@ The non-ECS fields listed below are beta and subject to change.
 
     </DocCell>
   </DocRow>
-    <DocRow>
+  <DocRow>
     <DocCell>`kibana.alert.workflow_assignee_ids`</DocCell>
     <DocCell>
       List of users assigned to an alert.
@@ -904,17 +904,25 @@ The non-ECS fields listed below are beta and subject to change.
 
     </DocCell>
   </DocRow>
-    <DocRow>
+  <DocRow>
     <DocCell> `kibana.alert.intended_timestamp`</DocCell>
     <DocCell>
       Shows the alert’s estimated timestamp, had the alert been created when the source event initially occurred. The value in this field is determined by the way the rule was run:
 
-         * **Scheduled run**: Alerts created by scheduled runs have the same timestamp as the `kibana.alert.rule.execution.timestamp` field, which shows when the rule was executed.
+         * **Scheduled run**: Alerts created by scheduled runs have the same timestamp as the `@timestamp` field, which shows when the alert was created.
          * **Manual run**: Alerts created by manual runs have a timestamp that falls within the time range specified for the manual run. For example, if you set a rule to manually run on event data from `10/01/2024 05:00 PM` to `10/07/2024 05:00 PM`, the `kibana.alert.intended_timestamp` value will be a date and time within that range.
 
-
       Type: date
 
     </DocCell>
   </DocRow>
+  <DocRow>
+    <DocCell> `kibana.alert.rule.execution.type`</DocCell>
+    <DocCell>
+      Shows if an alert was created by a manual run or a scheduled run. The value can be `manual` or `scheduled`. 
+
+      Type: keyword
+      
+    </DocCell>
+  </DocRow>
 </DocTable>

docs/serverless/alerts/alert-suppression.mdx

@@ -12,7 +12,7 @@ status: in review
 <DocCallOut color="warning" title="Requirements and notice">
     - ((ml-cap)) rules have <DocLink slug="/serverless/security/ml-requirements">additional requirements</DocLink> for alert suppression.
 
-    - Alert suppression is in technical preview for threshold, indicator match, event correlation, and new terms rules. The functionality may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features.
+    - Alert suppression is in technical preview for event correlation rules. The functionality may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features.
 </DocCallOut>
 
 Alert suppression allows you to reduce the number of repeated or duplicate detection alerts created by these detection rule types:

docs/serverless/rules/rules-ui-create.mdx

@@ -49,7 +49,7 @@ To create or edit ((ml)) rules, you need an appropriate user role. Additionally,
 
     1. The anomaly score threshold above which alerts are created.
 
-1. <DocBadge template="technical preview" /> (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <DocLink slug="/serverless/security/alert-suppression">Suppress detection alerts</DocLink> for more information.
+1. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <DocLink slug="/serverless/security/alert-suppression">Suppress detection alerts</DocLink> for more information.
 
     <DocCallOut title="Note">
     Because ((ml)) rules generate alerts from anomalies, which don't contain source event fields, you can only use anomaly fields when configuring alert suppression.
@@ -141,7 +141,7 @@ To create or edit ((ml)) rules, you need an appropriate user role. Additionally,
         Alerts created by threshold rules are synthetic alerts that do not resemble the source documents. The alert itself only contains data about the fields that were aggregated over (the **Group by** fields). Other fields are omitted, because they can vary across all source documents that were counted toward the threshold. Additionally, you can reference the actual count of documents that exceeded the threshold from the `kibana.alert.threshold_result.count` field.
         </DocCallOut>
 
-1. <DocBadge template="technical preview" /> (Optional) Select **Suppress alerts** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <DocLink slug="/serverless/security/alert-suppression">Suppress detection alerts</DocLink> for more information.
+1. (Optional) Select **Suppress alerts** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <DocLink slug="/serverless/security/alert-suppression">Suppress detection alerts</DocLink> for more information.
 
     {/* The following steps are repeated across multiple rule types. If you change anything 
     in these steps or sub-steps, apply the change to the other rule types, too. */}
@@ -285,7 +285,7 @@ To create or edit ((ml)) rules, you need an appropriate user role. Additionally,
         they can be selected here. When alerts generated by the rule are investigated in the Timeline, Timeline query values are replaced with their corresponding alert field values.
         </DocCallOut>
 
-1. <DocBadge template="technical preview" /> (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <DocLink slug="/serverless/security/alert-suppression">Suppress detection alerts</DocLink> for more information.
+1. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <DocLink slug="/serverless/security/alert-suppression">Suppress detection alerts</DocLink> for more information.
 
     {/* The following steps are repeated across multiple rule types. If you change anything 
     in these steps or sub-steps, apply the change to the other rule types, too. */}
@@ -352,7 +352,7 @@ You uploaded a value list of known ransomware domains, and you want to be notifi
 
         For example, if a rule has an interval of 5 minutes, no additional look-back time, and a history window size of 7 days, a term will be considered new only if the time it appears within the last 7 days is also within the last 5 minutes. Configure the rule interval and additional look-back time when you <DocLink slug="/serverless/security/rules-create" section="set-the-rules-schedule">set the rule's schedule</DocLink>.
 
-1. <DocBadge template="technical preview" /> (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <DocLink slug="/serverless/security/alert-suppression">Suppress detection alerts</DocLink> for more information.
+1. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <DocLink slug="/serverless/security/alert-suppression">Suppress detection alerts</DocLink> for more information.
 
     {/* The following steps are repeated across multiple rule types. If you change anything 
     in these steps or sub-steps, apply the change to the other rule types, too. */}
@@ -389,7 +389,7 @@ To create an ((esql)) rule:
     Click the help icon (<DocIcon type="iInCircle" title="Click the ES|QL help icon" />) to open the in-product reference documentation for all ((esql)) commands and functions.
     </DocCallOut>
 
-1. <DocBadge template="technical preview" /> (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <DocLink slug="/serverless/security/alert-suppression">Suppress detection alerts</DocLink> for more information.
+1. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <DocLink slug="/serverless/security/alert-suppression">Suppress detection alerts</DocLink> for more information.
 
     {/* The following steps are repeated across multiple rule types. If you change anything 
     in these steps or sub-steps, apply the change to the other rule types, too. */}