Metrics like response time (RT) and queries per second (QPS) fluctuate throughout the day -- what looks normal at noon may signal an attack at midnight. Static thresholds cannot adapt to these patterns, resulting in missed alerts or false positives. Dynamic thresholds solve this by learning your metric's normal behavior and adjusting the expected range over time. Dynamic threshold-based anomaly detection is mainly used to monitor metrics whose trends are stable. If data points exceed the calculated boundaries, the system generates exception events.
For example, a website's page view count normally stays above 1,000 between 10:00 and 18:00. If page views remain above 1,000 between 22:00 and 06:00, the site may be under attack. A static threshold of 1,000 triggers daytime alerts when traffic dips but misses the nighttime anomaly. Dynamic thresholds catch this because the expected range adjusts based on time of day.
Use cases
| Scenario | Monitored metrics | What dynamic thresholds detect |
|---|---|---|
| Application performance | Response time, request rate | Sudden latency spikes or traffic drops that deviate from daily patterns |
| Server resource optimization | CPU utilization, memory usage | Sustained resource consumption above the learned baseline, signaling a need for capacity adjustment |
| Connection pool analysis | Query rate, concurrent connections | Thread pool exhaustion or abnormal connection patterns |
| Microservice health | Per-service resource usage, response time | Anomalies in individual services within a complex dependency chain |
How it works
Application Real-Time Monitoring Service (ARMS) uses the Prophet algorithm to build a predictive model for each metric:
Every 24 hours, ARMS analyzes the last 7 days of historical data.
The algorithm extracts the metric's trend (long-term direction) and seasonality (repeating daily or weekly patterns).
ARMS then predicts the expected data range for the next 24 hours and calculates upper and lower boundaries.
If a data point falls outside the predicted range, ARMS generates an alert event.
Because ARMS recalibrates daily, the boundaries adapt to gradual changes in metric behavior -- such as traffic growth or infrastructure changes -- without manual rule updates.
Dynamic thresholds require sufficient historical data to produce accurate predictions. For a newly created metric, allow at least 7 days of data collection before the algorithm can establish a reliable baseline.
Prerequisites
Before you begin, make sure that you have:
Application data reported to Managed Service for OpenTelemetry. For more information, see Connection Description
Create a dynamic threshold alert rule
Log on to the ARMS console.
In the left-side navigation pane, choose Application Monitoring > Application Monitoring Alert Rules.
On the Application Monitoring Alert Rules page, choose Create Alert Rule > Managed Service for OpenTelemetry Alert Rule.
On the Create Alert Rule page, enter an alert rule name and select Interval Detection for the Alert Detection Type parameter.
In the Alert Contact section, configure the application, metric type, and filter condition.
- The available Alert Condition and Filter Condition options depend on the selected Metric Type. - Initial chart rendering takes about 2 to 4 seconds. - For details on how upper and lower boundaries are calculated, see Threshold calculation.
Parameter Description Select Applications The application to monitor. Dynamic threshold detection supports one application per rule. Metric Type The metric to monitor. After you select a metric, ARMS calculates the upper and lower boundaries and renders a real-time preview in the Alert Condition section. For available metrics, see Alert rule metrics. Filter Condition Narrows the monitoring scope. Options: Traverse (checks all values and reports whichever triggers the alert), No Dimension (aggregates all values into a sum), = / != (exact match or exclusion), Contain / Do Not Contain (partial match or exclusion), Match Regular Expression. 
In the Alert rules section, configure the alert condition.
Parameter Description Alert trigger mode Single condition. Alert Condition Define the detection criteria: - Last X minutes: monitoring window (maximum: 60 minutes). - Data: the data type to monitor (for example, number of calls or response time). - Calculation method: how the data is aggregated (average, maximum, minimum, and others). - Comparison method: how to detect anomalies. Choose based on your metric: -- Outside the range of the dynamic threshold: alerts when a data point falls above the upper boundary or below the lower boundary. Use for metrics where both spikes and drops matter, such as QPS. -- Larger than the maximum value of the dynamic threshold: alerts when a data point exceeds the upper boundary. Use for metrics where only spikes matter, such as response time or error rate. -- Lower than the minimum value of the dynamic threshold: alerts when a data point drops below the lower boundary. Use for metrics where only drops matter, such as throughput or success rate. - Alert level: severity of the alert -- P1, P2, P3, or P4. Tolerance Controls the width of the allowed data range. Use a higher tolerance (wider range, fewer alerts) for volatile metrics or during initial setup. Use a lower tolerance (narrower range, more alerts) for business-critical services that require tight monitoring. Alert Quantity Prediction Displays the predicted number of alerts within the specified time period. Click the count to view the historical data points that would have triggered alerts. Use this each time you create or modify a rule to validate that your tolerance produces a reasonable alert volume. See Alert quantity prediction. Configure the Alert Notification and Advanced Alert Settings sections.
Parameter Description Alert Notification Simple Mode - Notification Objects: select or create contacts. See Notification objects. - Notification Period: the time window during which alert notifications are sent. - Whether to Resend Notifications: without an escalation policy, each alert notification is sent only once before the alert clears. To receive repeat notifications, specify a resend interval. Notifications repeat at this interval until the alert clears. Standard Mode Notification Policy: - Do Not Specify Notification Policy: no notification is sent when an alert fires. Notifications are sent only when a separate notification policy's matching rules apply. - Specify a notification policy: ARMS sends notifications through the selected policy. Select an existing policy or create one. See Create and manage a notification policy. Advanced Alert Settings No data Handles data anomalies such as missing data, abnormal composite metrics, or abnormal period-over-period comparison results. When fixable, the alert data is automatically changed to 0 or 1, or the alert is suppressed. See Terms. Click Save.
Threshold calculation
ARMS recalculates dynamic thresholds every 24 hours using the Prophet algorithm:
Data collection: ARMS reads the last 7 days of metric data.
Decomposition: The algorithm separates the metric into trend (long-term direction) and seasonality (recurring daily or weekly cycles).
Prediction: ARMS generates a predicted value for each point in the next 24 hours.
Boundary calculation: An expected data range (upper and lower boundaries) is derived from the metric's historical fluctuations.
Because ARMS re-analyzes trends daily and predicts only the next day's boundaries, the thresholds adapt to gradual changes in metric behavior without manual updates.
In the chart above, blue represents data points and green represents the allowed data range.
Alert quantity prediction
Alert quantity prediction applies the current detection settings against historical data to estimate how many alerts would have fired. This helps fine-tune tolerance and alert conditions before the rule goes live.
How it works:
ARMS reads the last 24 hours of metric data.
For each data point, it checks whether the value would have exceeded the configured thresholds.
It returns the total predicted alert count and the specific timestamps that would have triggered alerts.
Adjust tolerance and comparison method settings, then re-run the prediction until the alert volume matches your operational expectations.
FAQ
When should I use dynamic thresholds instead of static thresholds?
Use dynamic thresholds for metrics with predictable daily or weekly patterns where a fixed threshold would produce excessive false positives or miss real anomalies. Common examples include response time, QPS, page views, and CPU utilization. If your metric has no recurring pattern or rarely changes, a static threshold may be simpler and equally effective.
What happens when a metric is new and has limited historical data?
ARMS requires historical data from the last 7 days to build its predictive model. For metrics with less than 7 days of data, the predicted boundaries may be inaccurate and produce false positives or missed alerts. Allow at least 7 days of data collection before relying on dynamic thresholds for a new metric.
How often are thresholds recalculated?
ARMS recalculates thresholds once every 24 hours. Each recalculation uses the most recent 7 days of data, so the boundaries continuously adapt to gradual changes in metric behavior.
What's next
View alert events: In the left-side navigation pane, choose Alert Management > Alert Event History. See View historical alert events.
Manage triggered alerts: In the left-side navigation pane, choose Alert Management > Alert Sending History. From here, claim, clear, or block alerts, or assign a handler. See View historical alerts.