Overview
This article answers common questions about setting up monitoring rules, configuring escalation policies, and managing alert behavior in the Business Activity Monitoring (BAM) Pull Model.
Business value
Understanding how Pull Model monitoring works — particularly how query monitoring differs from the Push Model's event-driven rules — helps teams configure alerts that catch real issues without generating noise during normal operations.
How it works
This article covers questions across three areas: available monitoring rule types, escalation policy configuration, and alert behavior. Where Pull Model monitoring behavior differs from the Push Model, differences are noted explicitly.
FAQs
-
What monitoring rule types are available in the Pull Model?
The Pull Model supports query monitoring only. Unlike the Push Model — which includes duration monitoring, exception monitoring, query monitoring, and summary alerts — the Pull Model's monitoring capability is built entirely around scheduled KQL queries evaluated against threshold conditions. Query monitoring can cover both volume-based conditions (too many failures) and absence-based conditions (too few transactions) depending on how you write the query. See Query monitoring for setup instructions. -
How does query monitoring work in the Pull Model?
A query monitoring rule runs a scheduled KQL query against a connected data source (Application Insights, Log Analytics, or ADX) and evaluates the result against warning and error thresholds. The evaluation interval is set by the Rules evaluation frequency field — for example, every 15 minutes. When a threshold is met, BAM sends an alert up to the Maximum alerts per hour limit. Pull Model query monitoring queries your source data directly, meaning it can detect conditions even when no transaction instance has been created in BAM yet. See Query monitoring for the full configuration walkthrough. -
What is an escalation policy, and how do I connect it to a monitoring rule?
An escalation policy defines who gets notified, through which channel, and when. In the Pull Model, escalation policies are available in Basic alert configuration mode only — they cannot be assigned to individual query rules in Advanced mode. Create the escalation policy first under Managing escalation policies, then select it during query monitoring configuration when using Basic mode. -
What is the difference between Basic and Advanced alert configuration?
In Basic alert configuration, all query rules in the business process share the same escalation policy, notification channels, and email recipients. This is the simpler option when all alerts should route to the same team. In Advanced alert configuration, each query rule has its own notification channels, thresholds, and aggregation period — but escalation policies are not available in this mode. Use Advanced mode when different queries need different routing or sensitivity. See Query monitoring for the configuration steps for each mode. -
Can I apply multiple monitoring rules to the same business process?
Yes. You can add any number of query rules to a single business process, using either the Transaction or Custom query type for each. Each rule is evaluated independently on the same evaluation frequency. Use multiple rules when different aspects of the same business process require separate threshold conditions or notification routing. -
How do I know when a monitoring rule has triggered? Where do I see the resulting alerts?
Alert incidents are created in the Alert incidents view under Business Activity Monitoring > Alert Management. Each incident records the rule that triggered, the time of evaluation, and the data that met the threshold condition. See Managing alert incidents for guidance on reviewing and resolving incidents. -
What is the difference between Rules evaluation frequency and Maximum alerts per hour?
Rules evaluation frequency controls how often BAM runs your queries — for example, every 15 minutes. Maximum alerts per hour limits how many alert notifications BAM actually sends within an hour, regardless of how many threshold violations the evaluation finds. The two settings work together: the frequency determines when evaluations happen, and the hourly cap prevents notification flooding when a threshold is continuously met across multiple evaluation cycles. -
Is there a way to test a monitoring rule without waiting for the evaluation cycle?
There is no manual trigger for query monitoring rules in the Pull Model. To verify a rule before the next evaluation cycle runs, test the KQL query directly in the Application Insights or Log Analytics portal to confirm it returns the expected scalar value, then confirm the threshold condition and comparison operator are set correctly in the rule configuration.