When application performance degrades -- a spike in jank counts after a release, or Largest Contentful Paint (LCP) times climbing on a critical page -- you need to know immediately. Static threshold alerts in Real User Monitoring (RUM) fire when a metric crosses a value you define, and deliver notifications to contacts or DingTalk group chats based on the specified notification methods.
When to use static thresholds
Static thresholds work best when you have a known acceptable range for a metric:
Web and HTML5 applications -- Monitor Core Web Vitals such as LCP, First Input Delay (FID), and Cumulative Layout Shift (CLS). Get alerted when page performance drops below acceptable levels.
iOS and Android apps -- Monitor resource loading, API calls, crashes, and janks. Application Real-Time Monitoring Service (ARMS) supports automatic reporting of abnormal stacks and crash logs to speed up root cause analysis.
Example scenario: After releasing a new app version, jank counts increase significantly. A static threshold on jank count triggers an alert, letting you identify and fix the issue before more users are affected.
Prerequisites
Before you begin, ensure that you have:
An application monitored in RUM. For setup instructions, see Integrate applications
Create a static threshold alert rule
Log on to the ARMS console.
In the left-side navigation pane, choose .
Click Create an alert rule.
Enter a rule name and set Alert Detection Type to Threshold Detection.
NoteUse a descriptive name that includes the severity, metric, and target -- for example,
P2 | High LCP | WebPortal.
Define the monitoring scope
In the Alert Contact section, specify which applications and metrics to monitor.
Parameter | Description |
Select Applications | Select one or more applications, or select all applications. |
Automatically apply this alert rule to newly created applications | When enabled, this rule automatically applies to applications added to RUM in the future. |
Metric Type | Select the category of metric to monitor. The available options for Alert Condition and Filter Condition change based on this selection. For the full list of supported metrics, see Alert metrics. |
Filters | Narrow the monitoring scope by filtering metric data along specific dimensions. Filter operators: Traverse (match all values), = / != (exact match or exclude), Contain / Do Not Contain (partial match or exclude). |
To include dimension details in alert notifications, specify the dimension in Filters. Otherwise, the data is aggregated in the metric query results.
Set alert conditions
In the Alert Rules section, define when alerts fire.
Parameter | Description |
Alert Triggering Mode | Single Condition -- Define one condition. Multiple Conditions -- Define multiple conditions and set Alert Triggering Rules to either Meet All the Following Rules (all conditions must be true) or Meet One of the Following Rules (any condition triggers the alert). |
Alert Condition | Configure the threshold. Select a Time Period (the evaluation window in minutes, for example |
Alert Level | Assign a severity level. ARMS provides four built-in levels: P1 (critical), P2 (error), P3 (warning), P4 (page). Configure notification policies per level -- for example, phone calls for P1 alerts and DingTalk messages for P3/P4. |
Enter P4 recommended threshold | Auto-generate a baseline threshold using the ARMS intelligent algorithm. You can adjust the threshold based on the metrics shown in the chart preview section. See Recommended thresholds for details. To generate per-application thresholds, click the |
Alert Quantity Prediction | Preview how many alerts a given threshold would trigger. Click the predicted number to query the data that is expected to trigger alerts at historical points in time. See Alert quantity prediction for details. |
icon next to Application.After you create a rule, check the alert notification to evaluate whether the threshold is reasonable and whether it has recently been triggered. See View alert details.
Configure notifications and advanced settings
Parameter | Description |
Notification Policy | Choose how alert notifications are delivered. Do Not Specify Notification Policy -- No notification is sent when the alert fires. Notifications are sent only when a separate notification policy's matching rules are triggered. Specify a notification policy -- Select an existing policy or create one. For more information, see Create and manage a notification policy. |
No data (under Advanced Alert Settings) | Handle missing or anomalous data, such as gaps in collection, abnormal composite metrics, or invalid period-over-period comparisons. When fixable, ARMS automatically replaces the value with 0 or 1, or suppresses the alert. For more information, see Terms. |
Save the rule
Click Save.
View alert details
After an alert fires, review it in the ARMS console by navigating to Alert Management > Alert Event History.
The Alert Event History page does not support direct navigation to the RUM module in two cases:
The alert condition uses aggregation metrics (such as number of anomalies, resources, or janks).
The alert condition uses period-over-period comparison (such as Month-on-Month Increase %, Month-on-Month Decrease %, Hour-on-Hour Increase %, Hour-on-Hour Decrease %, Day-on-Day Increase %, or Day-on-Day Decrease %).
Investigate an alert event
On the Alert Event History page, click an alert event name to view its details. For more information, see View historical alert events.
To examine the raw data that triggered the alert, click the event URL to open the Data Exploration page in the RUM module.
Recommended thresholds
ARMS analyzes historical data to generate recommended static thresholds for each application, interface, and metric combination. A preview chart lets you compare the recommended values against actual metric trends before applying them.
When to use recommended thresholds
Noisy alerts -- Alerts fire frequently but the system runs normally. The current threshold may not fit certain applications or interfaces. Use recommended thresholds to recalibrate.
Large-scale configuration -- Different applications or interfaces need different thresholds for the same metric. The intelligent algorithm generates per-target recommendations for quick configuration.
How it works
When you click Enter P4 recommended threshold, ARMS pulls metric data from the last three days for each application and interface. It applies the N-sigma algorithm to compute the mean and variance for each metric. Assuming steady-state behavior and a normal distribution, values beyond three standard deviations are statistically rare -- this defines the recommended threshold.
P4 is the lowest severity level, so a P4 threshold flags metrics that are slightly abnormal. Use it as a baseline and set tighter thresholds for P1, P2, and P3.
Alert quantity prediction
The alert prediction feature estimates how many alerts a threshold would generate, based on historical data. Use it to fine-tune thresholds before activating a rule.
How it works
ARMS analyzes metric data from the last 24 hours and counts how many times each threshold was exceeded. The results include specific timestamps for each breach, making it straightforward to assess whether the threshold captures real issues or generates noise. Adjust the threshold based on these findings.
Run the alert prediction check each time you create or modify an alert rule.