Documentation Index

Fetch the complete documentation index at: https://docs.turbo360.com/llms.txt

Use this file to discover all available pages before exploring further.

Query monitoring

  • 8 minute(s) read
Prev Next

Overview

Query monitoring in the Pull Model lets you run scheduled queries against your external data sources — Azure Application Insights, Log Analytics, or Azure Data Explorer (ADX) — and receive alerts when the results meet or exceed configured thresholds. You define what to query, how to evaluate the results, and where to route alerts when a condition is triggered.

Unlike Push Model query monitoring, which evaluates queries against data BAM has already received via the BAM API, Pull Model query monitoring queries your source data directly. This means you can detect issues — such as missing transaction counts, unexpected failure rates, or data anomalies — even when no transaction instance has been created in BAM yet.

Business value

Pull Model query monitoring lets you proactively surface operational signals from your existing observability data without modifying your integrations. By configuring threshold-based alerts on scheduled queries, your operations team is notified of anomalies as they emerge — rather than discovering them after a customer raises a support request.

Prerequisites

  • A Pull Model (Data Queries) business process must exist before you can configure query monitoring.
  • The data source (Application Insights workspace, Log Analytics workspace, or ADX cluster) must be connected and accessible from the BAM service principal.

Required permissions

Permission Access level
View Query monitor settings Required to view query monitoring configuration
Manage Query monitor settings Required to create or modify query monitoring rules
Manage monitor settings Required to enable or disable monitoring for the business process or group

How it works

Query monitoring works by running queries on a schedule — defined by the Rules evaluation frequency — and evaluating each result against the warning and error thresholds you configure. When a threshold is met, BAM sends an alert to the notification channels you have selected, up to the Maximum alerts per hour limit.

Pull Model query monitoring supports two query types:

  • Transaction — Uses a pre-configured transaction query as the base. Select a transaction defined in the business process; BAM constructs the query from the transaction's data source configuration.
  • Custom — Write your own KQL query directly against the connected data source. Custom queries must return a scalar result. BAM evaluates the returned value against the configured thresholds.

You can choose from two alert configuration modes:

  • Basic alert configuration — All queries share the same notification channels and email recipients. Escalation policy assignment is available in this mode.
  • Advanced alert configuration — Notification channels, thresholds, and aggregation periods are configured individually per query. Use this when different queries require different routing or sensitivity.

Steps

Use the following steps to configure query monitoring for a Pull Model business process. Navigate to Business Activity Monitoring > your business process > Monitoring to get started.

Configure alert settings

Set the evaluation schedule and alert rate limit before adding queries.

  1. Select the Query monitor tab under the Monitoring tab.
  2. Set the Rules evaluation frequency — the interval at which BAM runs your queries and evaluates results against thresholds. For example, setting this to 15 minutes runs the queries every 15 minutes.
  3. Set the Maximum alerts per hour — the maximum number of alert notifications BAM sends per hour, regardless of how many threshold violations occur.
  4. Select Basic alert configuration or Advanced alert configuration depending on how you want to route alerts.

Configure basic alert configuration

In basic mode, all query rules share the same escalation policy and notification channels.

  1. Select Basic alert configuration.
  2. Select an Escalation policy if required. Escalation policy is only available in basic mode.
  3. Enter a Recipient email address and select an Email template.
  4. Under Select the channels, check each notification channel that should receive the alert.
  5. Click Update to save.

Add a query (advanced alert configuration)

In advanced mode, each query is added as an individual rule with its own data source, thresholds, and notification routing.

  1. Select Advanced alert configuration.
  2. Click + Add query.
  3. Enter a Query name.
  4. Set the Aggregation period — the time window BAM uses to evaluate the query results (e.g. Last 15 minutes).
  5. Select the Query type:
    • Transaction — Select a transaction from the Select transaction dropdown. BAM uses the transaction's pre-configured data source query as the base.
    • Custom — Select the target resource from the Select resource dropdown, then enter your KQL query in the Query field. Only scalar queries are supported — the query must return a single numeric value.
  6. Set the Condition — the operator used to compare the query result against the thresholds (e.g. >).
  7. Set the Warning threshold — BAM fires a warning alert when the result meets this condition.
  8. Set the Error threshold — BAM fires an error alert when the result meets this condition.
  9. Optionally enter a Note — shown on the query rule for reference and included in alert notifications.
  10. Configure the Recipient email address, Email template, and notification channels for this query rule.
  11. Click + Add to save the query rule.

Enable or disable monitoring

You can enable or disable all monitoring rules for a business process without deleting your configuration. This is useful during maintenance or testing periods.

  1. Navigate to Business Activity Monitoring > your business process > Monitoring.
  2. In the top-right corner, open the Monitoring status dropdown.
  3. Select Enable to activate monitoring, or Disable to pause all monitoring rules.
Note:

Enabling and disabling monitoring requires the Manage monitor settings permission. This action affects all monitor types for the selected business process simultaneously.

Configuration

Option Type Description
Rules evaluation frequency Selection How often BAM runs queries and evaluates results against thresholds
Maximum alerts per hour Integer Cap on alert notifications sent per hour across all monitored queries
Alert configuration mode Selection Basic (shared channels and escalation policy) or Advanced (per-query channels)
Escalation policy Selection Available in basic mode only; escalates unresolved alerts after a defined interval
Query name Text Display name for the query rule
Aggregation period Selection Time window used to evaluate the query result; configurable per query in advanced mode
Query type Selection Transaction (pre-configured query) or Custom (write your own KQL)
Select transaction Selection Available when query type is Transaction; selects the transaction whose data source query is used
Select resource Selection Available when query type is Custom; selects the App Insights, Log Analytics, or ADX resource to query against
Query Text (KQL) The KQL query to execute against the selected resource; must return a scalar value
Condition Selection Operator used to compare the query result against thresholds (e.g. >)
Warning threshold Integer Query result value at which a warning alert fires
Error threshold Integer Query result value at which an error alert fires
Note Text Optional label shown on the query rule; included in alert notifications
Monitoring status Selection Enable or disable all monitoring rules for the business process

Limitations

  • Custom queries must return a scalar (single numeric) result. Tabular queries that return multiple rows or columns are not supported.
  • Advanced queries are not shared with the Tracking section of the business process. Queries added in the Query monitor section do not appear in the Tracking view, and vice versa.
  • Escalation policy assignment is available in basic alert configuration mode only.
  • Disabling monitoring via the Monitoring status dropdown suspends all monitor types for the business process, not only query monitoring.
  • Query monitoring is configured per business process. You cannot monitor queries across multiple business processes from a single query monitor.

Troubleshooting

  1. Custom query returns an error or no results
    Cause: The query may not return a scalar result, or the selected resource may not be accessible.
    Fix: Verify the query returns a single numeric value. Confirm the data source resource is connected and the service principal has Reader access. Test the query directly in the Application Insights or Log Analytics portal before saving.

  2. No alert was received after the evaluation frequency elapsed
    Cause: Monitoring may not be enabled, or the query result did not meet the configured threshold.
    Fix: Open the Monitoring tab and confirm Monitoring status is set to Enabled. Verify the query returns a value that satisfies the configured condition and threshold.

  3. Transaction query type shows no transactions in the dropdown
    Cause: No transactions have been configured in this business process yet.
    Fix: Configure at least one transaction under the Transactions tab before setting up query monitoring with the Transaction query type.

  4. Escalation policy option is not visible
    Cause: The alert configuration mode is set to Advanced. Escalation policy is only available in basic mode.
    Fix: Switch to Basic alert configuration to access the escalation policy option.

  5. Alert volume is too high
    Cause: The Maximum alerts per hour limit may be too high, or a query is matching frequently.
    Fix: Lower the Maximum alerts per hour value, or adjust the query threshold to reduce false positives.

FAQs

  1. What is the difference between the Transaction and Custom query types?
    The Transaction type uses the data source query already configured on a transaction in this business process — no additional KQL is required. The Custom type lets you write your own KQL query against any connected App Insights, Log Analytics, or ADX resource, giving you full control over what is evaluated.

  2. What does "only scalar queries are supported" mean?
    BAM evaluates the query result as a single number and compares it against the warning and error thresholds. Your KQL query must return exactly one row with one numeric column. Queries that return tables or multiple values are not supported for query monitoring.

  3. What is the difference between Rules evaluation frequency and Maximum alerts per hour?
    Rules evaluation frequency controls how often BAM executes 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.

Related articles