From 95a29cdff87571b6cfbc2ce8984075859bf6b995 Mon Sep 17 00:00:00 2001 From: Hannah Brooks Date: Wed, 18 Feb 2026 15:11:26 -0500 Subject: [PATCH 1/2] added note --- .../security/detect-and-alert/create-detection-rule.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/solutions/security/detect-and-alert/create-detection-rule.md b/solutions/security/detect-and-alert/create-detection-rule.md index 58da53009b..00f09d9ec6 100644 --- a/solutions/security/detect-and-alert/create-detection-rule.md +++ b/solutions/security/detect-and-alert/create-detection-rule.md @@ -512,7 +512,11 @@ When writing your query, consider the following: If the `LIMIT` value and **Max alerts per run** value are different, the rule uses the lower value to determine the maximum number of alerts the rule generates. * When writing an aggregating query, use the [`STATS...BY`](elasticsearch://reference/query-languages/esql/commands/processing-commands.md#esql-stats-by) command with fields that you want to search and filter for after alerts are created. For example, using the `host.name`, `user.name`, `process.name` fields with the `BY` operator of the `STATS...BY` command returns these fields in alert documents, and allows you to search and filter for them from the Alerts table. -* When configuring alert suppression on a non-aggregating query, we recommend sorting results by ascending `@timestamp` order. Doing so ensures that alerts are properly suppressed, especially if the number of alerts generated is higher than the **Max alerts per run** value. +* When configuring alert suppression on a non-aggregating query, we recommend sorting results by ascending `@timestamp` order. Doing so ensures that alerts are properly suppressed, especially if the number of alerts generated is higher than the **Max alerts per run** value. + + ::::{note} + If your query uses the [`MV_EXPAND`](elasticsearch://reference/query-languages/esql/commands/processing-commands.md#esql-mv_expand) command, add a tiebreaker field such as `_index` to your `SORT` command (for example, `SORT @timestamp ASC, _index ASC`). `MV_EXPAND` can produce multiple rows with identical timestamps, and without a tiebreaker, the sort order of those rows is undefined, which can lead to inconsistent alert suppression results. + :::: ### {{esql}} rule limitations [esql-rule-limitations] From d5ac2cdb9514deaa284cbbffe9c097bf3a389701 Mon Sep 17 00:00:00 2001 From: Hannah Brooks Date: Fri, 6 Mar 2026 15:42:17 -0500 Subject: [PATCH 2/2] update note --- solutions/security/detect-and-alert/create-detection-rule.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/solutions/security/detect-and-alert/create-detection-rule.md b/solutions/security/detect-and-alert/create-detection-rule.md index 00f09d9ec6..e5563e6711 100644 --- a/solutions/security/detect-and-alert/create-detection-rule.md +++ b/solutions/security/detect-and-alert/create-detection-rule.md @@ -515,7 +515,9 @@ When writing your query, consider the following: * When configuring alert suppression on a non-aggregating query, we recommend sorting results by ascending `@timestamp` order. Doing so ensures that alerts are properly suppressed, especially if the number of alerts generated is higher than the **Max alerts per run** value. ::::{note} - If your query uses the [`MV_EXPAND`](elasticsearch://reference/query-languages/esql/commands/processing-commands.md#esql-mv_expand) command, add a tiebreaker field such as `_index` to your `SORT` command (for example, `SORT @timestamp ASC, _index ASC`). `MV_EXPAND` can produce multiple rows with identical timestamps, and without a tiebreaker, the sort order of those rows is undefined, which can lead to inconsistent alert suppression results. + {{esql}} query results are primarily sorted by timestamp. However, when two or more rows share the same timestamp, another field is needed to determine their order. A tiebreaker field provides this secondary sort criteria and ensures that rows are sorted in ascending, lexicographic order. + + For instance, if your query uses the [`MV_EXPAND`](elasticsearch://reference/query-languages/esql/commands/processing-commands.md#esql-mv_expand) command (for example, `SORT @timestamp ASC, _index ASC`), multiple rows with identical timestamps will be produced. Without a tiebreaker field, the sort order of those rows is undefined, which can lead to inconsistent alert suppression results. ::::