When application metrics such as error rates, response times, or garbage collection counts exceed normal ranges, your team needs immediate visibility. Static thresholds let you define fixed limits for these metrics. When a metric breaches a threshold, the Application Monitoring sub-service of Application Real-Time Monitoring Service (ARMS) sends alert notifications to designated contacts so your team can respond before the issue affects users.
This topic walks you through creating a static threshold alert rule in Managed Service for OpenTelemetry: selecting applications and metrics, defining trigger conditions and severity levels, tuning thresholds with intelligent recommendations, and configuring notifications.
When to use static thresholds
Static thresholds work best when a metric has a clear boundary that should never be crossed, regardless of traffic patterns. Typical examples:
Hard operational limits: JVM memory usage, disk usage, or error rate exceeding a fixed ceiling.
SLA-driven targets: Response time or availability that must stay within a contractual limit.
Capacity boundaries: Thread pool utilization, connection pool exhaustion.
If your metrics fluctuate with traffic patterns (for example, request volume that peaks during business hours), consider dynamic baseline detection instead. Static thresholds do not adapt to periodic changes, which means a fixed limit may cause false alerts during expected traffic spikes or miss slow-growing anomalies such as memory leaks.
Prerequisites
Make sure that your application data is reported to Managed Service for OpenTelemetry. For setup instructions, see Connection description.
Create an alert rule
Log on to the Managed Service for OpenTelemetry console.
In the left-side navigation pane, choose .
On the Alert Rules page, click Create Alert Rule.
On the Create Alert Rule page, enter an alert rule name and set Alert Detection Type to Threshold Detection.
In the Alert Contact section, configure the metric scope.
Parameter Description Select Applications The applications to monitor. Select one, multiple, or all applications. Automatically apply this alert rule to newly created applications When enabled, this rule automatically applies to applications integrated with Managed Service for OpenTelemetry in the future. Metric Type The metric to monitor. The available Alert Condition and Filter Condition options change based on this selection. For the full list, see Alert rule metrics. Filter Condition Narrows the monitoring scope. See the following table for available options. Filter Condition options:
Option Behavior Traverse Evaluates each value of the metric individually. Values that breach the threshold appear in the alert notification. No Dimension Aggregates all values into a sum and displays the sum in the alert notification. = Includes only data that matches the specified metric values. != Excludes data that matches the specified metric values. Contain Includes only data whose metric values contain the specified values. Do Not Contain Includes only data whose metric values do not contain the specified values. Match Regular Expression Includes only data whose metric values match the specified regular expression. In the Alert rules section, configure the trigger mode and conditions.
Parameter Description Alert trigger mode Single Condition: triggers an alert when one condition is met. Multiple Conditions: requires configuring Alert Triggering Rules to define how conditions combine: Meet All the Following Rules (all conditions must be met) or Meet One of the Following Rules (any single condition triggers the alert). Alert Condition Defines the threshold expression. Assign different thresholds to severity levels P4 (lowest), P3, P2, and P1 (highest). You do not need to set thresholds for all levels. Setting only one level is also valid. For example, "average GC count > 1 triggers a P4 alert" is a complete rule.
Multiple conditions example -- combine error rate and call volume:
Click Add Condition to define multiple threshold expressions. Set Alert Triggering Rules to Meet All the Following Rules so that both conditions must be met:
Condition 1: Average error rate in the last 2 minutes >= 5%
Condition 2: Number of calls in the last 2 minutes >= 200
When you use Multiple Conditions, you must also set the Alert Level parameter. Severity levels in ascending order: P4, P3, P2, P1.
Single condition example -- JVM full garbage collections (GCs) in the last 5 minutes:
Severity Condition P4 Average GC count > 1 P3 Average GC count > 2 P2 Average GC count > 5 P1 Average GC count > 10 (Optional) Use recommended thresholds and alert prediction to fine-tune your rule.
Feature Description Enter P4 recommended threshold ARMS generates threshold recommendations based on historical metric data. To generate per-application recommendations, click the 
icon next to the application name. For details, see Recommended thresholds.Alert Quantity Prediction Predicts how many alerts the current thresholds would generate within a specified time period. Click the count to see which historical data points would have triggered alerts. For details, see Alert quantity prediction. In the Alert Notification section, select a notification mode.
Simple Mode:
Notification Objects: Create or select notification contacts. For details, see Notification objects.
Notification Period: Set the time window for sending notifications.
Whether to Resend Notifications: Without an escalation policy, a notification is sent only once before the alert clears. To receive repeat notifications, specify a resend interval. Notifications continue at this interval until the alert clears.
Standard Mode:
Notification Policy: Select how notifications are routed.
Do Not Specify Notification Policy: No notification is sent when an alert triggers. Notifications are sent only when matching rules of a notification policy are triggered.
Specify a notification policy: ARMS sends notifications using the method defined in the policy. Select an existing policy or create one. For details, see Create and manage a notification policy.
In the Advanced Alert Settings section, configure data anomaly handling.
Parameter Description No data Handles data anomalies such as missing data, abnormal composite metrics, and abnormal period-over-period comparison results. When fixable, the alert data is automatically changed to 0 or 1, or the alert is not triggered. For details, see Terms. Click Save.
Recommended thresholds
ARMS analyzes historical data to generate recommended static thresholds for each application and interface, helping you set accurate limits without manual guesswork.
When to use recommended thresholds
Noisy alerts: Alerts fire frequently for a metric, but the application runs normally. The threshold may be too aggressive or not tailored to specific applications or interfaces. Use recommended thresholds to adjust values per application.
Bulk configuration: You need to set different thresholds for a metric across many applications and interfaces. The intelligent algorithm generates tailored recommendations quickly.
How it works
Click Enter P4 recommended threshold to generate recommendations. ARMS pulls metric data from the last three days for each application and interface, then applies the N-sigma algorithm to calculate the mean and variance. Assuming a steady workload and normally distributed metrics, values beyond three standard deviations are statistically rare, making them natural threshold candidates.
A preview chart compares the recommended threshold against estimated values so you can adjust before saving.
P4 is the lowest severity level and flags slightly abnormal metrics. Use the P4 recommendation as a baseline, then set stricter thresholds for P3, P2, and P1 based on your operational requirements.
Alert quantity prediction
Alert quantity prediction estimates how many alerts the current thresholds would generate based on historical data, helping you validate thresholds before they go live.
How it works
Based on metric data from the last 24 hours, ARMS counts how many times each threshold was exceeded and predicts the future alert volume. ARMS also provides the exact times each threshold was breached so you can evaluate whether the thresholds match your operational expectations.
Use this feature each time you create or modify an alert rule to confirm that your thresholds produce a manageable alert volume.
What to do next
View alert events: In the left-side navigation pane, choose Alert Management > Alert Event History. For details, see View historical alert events.
Manage alert notifications: In the left-side navigation pane, choose Alert Management > Alert Sending History. From there, claim, clear, or block alerts, or assign a handler. For details, see View historical alerts.