Overview
This article covers common issues with monitoring rules and alert delivery in the Business Activity Monitoring (BAM) Pull Model. It addresses query monitoring not triggering, escalation policies failing to execute, and alert incidents not appearing as expected.
Business value
The Pull Model's monitoring capability depends on query results being correctly evaluated against configured thresholds. When monitoring fails silently, operational issues go undetected. This article helps you identify whether the failure is in the query, the rule configuration, or the escalation policy delivery.
How it works
Pull Model monitoring uses query monitoring rules — the only monitoring rule type in the Pull Model. Query monitoring runs scheduled KQL queries against your connected data sources (Application Insights, Log Analytics, or ADX) and evaluates each result against configured warning and error thresholds. The evaluation interval is set per business process using the Rules evaluation frequency field. When a threshold is met, BAM executes the linked escalation policy and sends a notification, up to the Maximum alerts per hour limit. Failures can occur at the query evaluation stage (no results match or query errors), the threshold comparison stage (condition not met as configured), or the escalation delivery stage (notification channel inactive or misconfigured).
FAQs
-
A query monitoring rule is active but no alert has been raised even though the data should meet the condition.
Cause: The most common causes are: the Monitoring status for the business process is not set to Enabled, the threshold comparison operator is configured incorrectly (for example,>instead of>=), or the query has not yet been evaluated since the rule was saved.
Fix: Open the Monitoring tab for the business process and confirm Monitoring status is Enabled. Open the query monitoring rule in Query monitoring and review the Condition, Warning threshold, and Error threshold values. Confirm they reflect the alerting intent. Wait for the next evaluation cycle (set by Rules evaluation frequency) and check whether an alert is raised. -
A custom query monitoring rule returns no results or an error.
Cause: Custom queries must return a scalar (single numeric) result. Tabular queries that return multiple rows or columns are not supported. The query may also reference a field that does not exist in the selected data source, or may be missing the required time field (TimeStampfor Application Insights,TimeGeneratedfor Log Analytics).
Fix: Test the query directly in the Application Insights or Log Analytics portal to confirm it returns a single numeric value. Ensure the query includes the required time field for the data source type. Correct any field references and save the updated rule. See Top tips for data queries for required query fields. -
An alert was raised but no notification was delivered through the escalation policy.
Cause: The notification channel configured in the escalation policy is inactive or has an expired configuration (for example, a rotated webhook URL or a deactivated Teams connector). In advanced alert configuration mode, escalation policies are not available — notifications are routed only through the per-query notification channels and email recipients.
Fix: Open the escalation policy under Escalation policies in the Pull Model and confirm the notification channel is active. Send a test message from the channel configuration to rule out a delivery issue. Note that escalation policies are only available in Basic alert configuration mode — if the rule uses Advanced mode, verify the per-query notification channels and email recipients are correctly configured instead. -
Alert incidents are not appearing in the alert incidents view even though monitoring rules are active.
Cause: Alert incidents are created only when a monitoring rule's threshold condition is met and the query returns a result. If the service principal's access policy does not cover the subscription being queried, or if the query itself errors, no incident is created.
Fix: Confirm the service principal has access to the subscriptions and data sources used by the monitoring rule. See Service principal troubleshooting for steps to diagnose access policy gaps. Then confirm the monitoring rule is Active, the Monitoring status is Enabled, and the query returns a numeric result when run manually against the Azure data source. -
Too many alerts are being generated — the alert volume is overwhelming the team.
Cause: The Maximum alerts per hour limit may be set too high, or a query threshold is set too sensitively and matches on most evaluation cycles.
Fix: Lower the Maximum alerts per hour value in the alert configuration settings to cap notification volume. Review the query threshold and condition — adjust the warning and error thresholds so they trigger only on meaningful deviations rather than normal operational variation. See Query monitoring for the full configuration options. -
Monitoring rules stopped triggering after updating the business process or transaction configuration.
Cause: Query monitoring rules that use the Transaction query type reference a specific transaction in the business process. If that transaction is renamed, deleted, or its data source configuration is changed significantly, the monitoring rule may no longer find matching data.
Fix: After any business process or transaction configuration change, open the Query monitor tab under Monitoring and review all active rules. For Transaction-type rules, confirm the selected transaction still exists and its data source query returns the expected data. For Custom-type rules, verify the query still returns valid scalar results against the data source. Update any rules that reference changed configuration.