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
Copy file name to clipboardExpand all lines: docs/en/observability/monitor-status-alert.asciidoc
+24-9Lines changed: 24 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -51,19 +51,35 @@ or a time range in which checks were run, and the minimum number of locations th
51
51
Retests are included in the number of checks.
52
52
====
53
53
54
-
The *Rule schedule* defines how often to evaluate the condition. Note that checks are queued, and they run as close
55
-
to the defined value as capacity allows. For example, if a check is scheduled to run every 2 minutes, but the check
56
-
takes longer than 2 minutes to run, a check will not run until the previous check has finished.
54
+
**Alert on no data** (optional): Enable this option to receive alerts when a monitor is in a **pending** state—that is, when no ping data has been received from the monitor for the evaluation period. This helps you detect monitors that have stopped reporting (for example, due to a misconfiguration, runner failure, or network issue). When this option is enabled:
57
55
58
-
You can also set *Advanced options* such as the number of consecutive runs that must meet the rule conditions before
59
-
an alert occurs.
56
+
* **Pending state**: A monitor is considered pending when no check results (pings) have been received within the rule's evaluation window. The alert reason follows the format: `Monitor "X" from Location Y is pending.`
57
+
* **Recovery**: The alert recovers automatically once the monitor reports data again, whether the result is up or down. No separate recovery action is required.
58
+
* **Action variables**: For pending-state alerts, the same <<synthetic-monitor-action-variables,action variables>> are available (such as `context.monitorName`, `context.monitorId`, `context.locationName`, `context.monitorUrl`, and `context.reason`). The `context.reason` and `context.message` fields reflect the pending status and monitor/location details.
59
+
60
+
The **Rule schedule** defines how often to evaluate the condition. Note that checks are queued, and they run as close to the defined value as capacity allows. For example, if a check is scheduled to run every 2 minutes, but the check takes longer than 2 minutes to run, a check will not run until the previous check has finished.
60
61
61
62
In this example, the conditions will be met any time a `browser` monitor is down `3` of the last `5` times
62
63
the monitor ran across any locations that match the filter. These conditions will be evaluated every minute,
63
64
and you will only receive an alert when the conditions are met three times consecutively.
64
65
65
66
[role="screenshot"]
66
-
image::images/synthetic-monitor-conditions.png[Filters and conditions defining a Synthetics monitor status rule,width=600]
67
+
image::images/serverless-synthetic-monitor-conditions.png[Filters and conditions defining a Synthetics monitor status rule,width=600]
68
+
69
+
You can also set **Advanced options** such as:
70
+
71
+
- **Alert delay**: The number of consecutive runs that must meet the rule conditions before an alert occurs.
72
+
73
+
- **Alert flapping detection**: Detect alerts that switch quickly between active and recovered states and reduce unwanted noise for these flapping alerts.
74
+
75
+
You can also customize the configuration through the following settings:
76
+
77
+
* **Rule run look back window**: The minimum number of runs in which the threshold must be met.
78
+
79
+
* **Alert status change threshold**: The minimum number of times an alert must switch states in the look-back window.
80
+
81
+
[role="screenshot"]
82
+
image::images/serverless-synthetic-monitor-advanced-settings.png[Advanced settings when defining a Synthetics monitor status rule,width=600]
67
83
68
84
[discrete]
69
85
[[synthetic-monitor-action-types]]
@@ -147,9 +163,8 @@ Learn how in <<migrate-monitor-rule>>.
147
163
Within the {uptime-app}, create a **Monitor Status** rule to receive notifications
148
164
based on errors and outages.
149
165
150
-
. To access this page, go to **{observability}** → **Uptime**.
151
-
. At the top of the page, click **Alerts and rules** → **Create rule**.
152
-
. Select **Monitor status rule**.
166
+
. To access this page, go to **Syntetics** → **Overview**.
167
+
. At the top of the page, click **Alerts** → **Monitor status rule** → **Create status rule**.
0 commit comments