Skip to content

Commit da9bb75

Browse files
committed
Port updates from 9.1
1 parent 5d5da33 commit da9bb75

3 files changed

Lines changed: 24 additions & 9 deletions

File tree

110 KB
Loading
108 KB
Loading

docs/en/observability/monitor-status-alert.asciidoc

Lines changed: 24 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -51,19 +51,35 @@ or a time range in which checks were run, and the minimum number of locations th
5151
Retests are included in the number of checks.
5252
====
5353

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:
5755

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.
6061

6162
In this example, the conditions will be met any time a `browser` monitor is down `3` of the last `5` times
6263
the monitor ran across any locations that match the filter. These conditions will be evaluated every minute,
6364
and you will only receive an alert when the conditions are met three times consecutively.
6465

6566
[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]
6783

6884
[discrete]
6985
[[synthetic-monitor-action-types]]
@@ -147,9 +163,8 @@ Learn how in <<migrate-monitor-rule>>.
147163
Within the {uptime-app}, create a **Monitor Status** rule to receive notifications
148164
based on errors and outages.
149165

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**.
153168

154169
[TIP]
155170
===============================

0 commit comments

Comments
 (0)