Monitoring and alerts troubleshooting

Prev Next

Overview

This article covers common issues with Business Activity Monitoring (BAM) monitoring rules and alert delivery. It addresses duration monitoring not triggering, exception monitoring producing false positives, summary alerts not firing, and escalation policies failing to execute.

Business value

Monitoring failures often go undetected until an incident is missed. This article helps you confirm whether a monitoring rule is correctly configured, identify why an expected alert was not sent, and resolve escalation policy failures before they affect incident response.

FAQs

  1. Duration monitoring is configured but no alert is raised even when a transaction exceeds the threshold.
    Cause: The most common causes are: the duration rule is not in Active status, the threshold is set in the wrong unit (hours vs minutes), or the transaction instance has not yet been evaluated by the monitoring cycle. Duration monitoring evaluates open instances on a scheduled cycle — an alert is not raised immediately when the threshold is crossed.
    Fix: Open the duration rule under Duration monitoring and confirm its status is Active. Verify the threshold value and unit match your intent. Then confirm the transaction instance in question is still open (not in a terminal stage) — duration monitoring only evaluates instances that have not yet completed. Wait for the next monitoring cycle to complete and check again.

  2. Exception monitoring raises alerts for transactions that completed successfully.
    Cause: The exception condition is matching a property value that appears in both failed and successful runs. Exception monitoring triggers when the configured property and value match an incoming message — if the value is not exclusive to failure scenarios, it will produce false positives.
    Fix: Review the exception condition configuration under Exception monitoring. Identify the property name and value used as the exception trigger. Verify in the source application that this value only appears in genuine failure messages. If the value appears in both successful and failed payloads, update the exception condition to use a more specific property or value combination that is exclusive to failures.

  3. Summary alerts are not firing at the expected time.
    Cause: Summary alerts run on a configured schedule. The most common causes of missed summary alerts are: the rule is not in Active status, the schedule time is set in UTC and the local timezone offset has not been accounted for, or no transactions matched the summary rule's filter criteria during the evaluation window.
    Fix: Open the summary alert rule under Summary alerts and confirm it is Active. Check the configured schedule time and convert it to your local timezone to confirm it matches your expectation. Review the filter criteria — if the rule filters by business process, transaction type, or status, confirm that transactions matching those criteria occurred during the evaluation window. If no matching transactions exist, the alert fires with zero results or is suppressed depending on your configuration.

  4. Query monitoring is not triggering despite data matching the query conditions.
    Cause: Query monitoring evaluates transaction data using the configured query at the monitoring cycle interval. If the monitoring cycle has not yet run since the matching data arrived, no alert will have been raised. Additionally, if the query returns more rows than the configured threshold but the threshold comparison operator is set incorrectly (for example, less than instead of greater than), the condition will never be met.
    Fix: Confirm the query monitoring rule is Active under Query monitoring. Review the threshold value and comparison operator — confirm they match the alerting intent. Wait for the next monitoring cycle and check whether an alert is raised. If the rule still does not trigger, run the query manually in the BAM tracking view to confirm it returns results matching the expected condition.

  5. An escalation policy is configured on a monitoring rule but notifications are not being sent.
    Cause: The most common causes are: the notification channel in the escalation policy is not active or has an invalid configuration (for example, an expired webhook URL or a deactivated email address), the escalation policy is not assigned to the correct monitoring rule, or the alert threshold has not been met the required number of consecutive times to trigger escalation.
    Fix: Open the escalation policy under Managing escalation policies and verify the notification channel is active and correctly configured. Confirm the policy is linked to the intended monitoring rule. Review the escalation trigger settings — if escalation requires multiple consecutive breaches, confirm that condition has been met. Test the notification channel independently (for example, send a test message from the channel configuration) to rule out a delivery issue with the channel itself.

  6. Monitoring rules were working previously but stopped triggering after a BAM environment update or redeployment.
    Cause: Redeploying the BAM environment can reset the monitoring engine state. Active monitoring rules may revert to Draft status or lose their association with the storage account if the storage connection string changed during redeployment.
    Fix: After any BAM redeployment, review all monitoring rules and confirm each is in Active status. If the storage connection string changed, update the BAM environment configuration under Environment setup and re-activate each rule. Reactivating a rule from Draft status re-registers it with the monitoring engine.

Related articles