You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| Active | Problem confirmed and ongoing. This is when you get notified. |
31
31
| Recovering | Errors have stopped, but the system is waiting to confirm it's truly resolved. |
32
32
33
+
<!-- TODO: Uncomment when PR #6523 (rules) is merged:
33
34
Activation and recovery thresholds control how many consecutive evaluations must agree, or how long the condition must persist, before transitioning. Refer to [Configure a rule](rules/configure-a-rule.md#activation-recovery-thresholds) to learn more about these settings.
35
+
-->
36
+
Activation and recovery thresholds control how many consecutive evaluations must agree, or how long the condition must persist, before transitioning.
34
37
35
38
### Example: First breach opens, first clear closes
36
39
@@ -43,9 +46,11 @@ A checkout-latency rule runs in Alert mode every 5 minutes. Latency breaches at
43
46
44
47
One problem is tracked in one episode, even though the rule evaluated many times while the condition was ongoing.
45
48
49
+
<!-- TODO: Add image once alert-episode-example-without-threshold.png is available in explore-analyze/images/
:alt: Timeline of a checkout-latency alert episode without thresholds. At 14:05, p95 jumps to 3.1s and the episode opens immediately as active. It stays active through 14:45. At 14:50, p95 drops back under 2s and the episode resolves immediately as inactive.
48
52
:::
53
+
-->
49
54
50
55
### Example: Waiting for confirmation before opening and closing
51
56
@@ -60,9 +65,11 @@ The same checkout-latency rule, now with an activation threshold of 2 consecutiv
60
65
61
66
Thresholds prevent brief spikes from opening episodes and transient dips from closing them prematurely. The episode waits in `pending` until the problem is confirmed, and waits in `recovering` until the resolution is confirmed.
62
67
68
+
<!-- TODO: Add image once alert-episode-example-with-activation-threshold.png is available in explore-analyze/images/
:alt: Timeline of a checkout-latency alert episode with activation threshold of 2 and recovery threshold of 2. At 14:05, the first breach puts the episode in pending. At 14:10, the second consecutive breach moves it to active. At 14:50, the first clean check moves it to recovering. At 14:55, the second consecutive clear resolves it to inactive.
65
71
:::
72
+
-->
66
73
67
74
## Series
68
75
@@ -72,7 +79,9 @@ Your rule monitors services. Each service it tracks has its own series, one for
72
79
73
80
Think of it like a patient's medical file. The file exists as long as the patient is in the system. Individual health incidents come and go, but the file persists.
74
81
82
+
<!-- TODO: Uncomment when PR #6523 (rules) is merged:
75
83
For the fields that identify a series in alert event documents, refer to [Rule event and field reference](rules/rule-event-field-reference.md#rule-reference).
Copy file name to clipboardExpand all lines: explore-analyze/alerting/kibana-alerting-experimental/alerts/alert-states-and-fields-reference.md
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,10 @@ description: "Reference for episode status, `.rule-events` row status, and `.ale
11
11
# Alert states and fields reference [alert-states-reference]
12
12
13
13
14
-
Alert states and fields are part of the experimental alerting features in Kibana. Use these tables when you read alert UI state, query `.rule-events` or `.alert-actions` in Discover, or align API payloads with what operators see. For triage controls (acknowledge, snooze, resolve, tags) and how they map to storage, refer to [Alert actions](view-and-manage-alerts.md#alert-actions). For rule evaluation fields on `.rule-events`, refer to [Rule event and field reference](../rules/rule-event-field-reference.md#rule-reference).
14
+
Alert states and fields are part of the experimental alerting features in Kibana. Use these tables when you read alert UI state, query `.rule-events` or `.alert-actions` in Discover, or align API payloads with what operators see. For triage controls (acknowledge, snooze, resolve, tags) and how they map to storage, refer to [Alert actions](view-and-manage-alerts.md#alert-actions).
15
+
<!-- TODO: Uncomment when PR #6523 (rules) is merged:
16
+
For rule evaluation fields on `.rule-events`, refer to [Rule event and field reference](../rules/rule-event-field-reference.md#rule-reference).
Copy file name to clipboardExpand all lines: explore-analyze/alerting/kibana-alerting-experimental/alerts/query-alerts-and-signals-in-discover.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,5 +22,8 @@ To use this page, open Discover, select {{esql}}, paste a query from the example
22
22
<!--[CONTENT NEEDED for M2: Review and expand the query examples below once M2 field renames (`group_hash` → `series.key`, new `series.tracked_by`, `episode.severity`, `episode.severity_max`) are finalized. Add examples that take advantage of the new first-class severity and series fields.]
23
23
-->
24
24
25
+
For field names, types, and episode fields, refer to [Alert states and fields reference](alert-states-and-fields-reference.md#alert-states-reference). For triage in the product UI, refer to [View, manage, and reference alerts](view-and-manage-alerts.md).
26
+
<!-- TODO: Uncomment when PR #6523 (rules) is merged and restore full sentence:
25
27
For field names, types, and episode fields, refer to [Alert states and fields reference](alert-states-and-fields-reference.md#alert-states-reference) and [Rule event and field reference](../rules/rule-event-field-reference.md#rule-reference). For triage in the product UI, refer to [View, manage, and reference alerts](view-and-manage-alerts.md).
0 commit comments