Overview
This article answers common questions about setting up monitoring rules, configuring escalation policies, working with summary alerts, and tuning alert thresholds in the Business Activity Monitoring (BAM) Push Model.
Business value
Monitoring and alerting are what make BAM operationally useful. Understanding how each rule type works, when to use it, and how escalation policies connect to notification channels helps you build a monitoring strategy that catches real issues without generating noise.
How it works
This article covers questions across four areas: monitoring rule types and their appropriate use cases, threshold configuration, escalation policy setup, and summary alert behavior. Questions progress from choosing the right rule type through to fine-tuning delivery.
FAQs
-
What monitoring rule types are available in the Push Model, and when should I use each one?
The Push Model supports four rule types. Use duration monitoring when you need to detect transactions that take longer than expected to complete — for example, an order that has not progressed past the payment stage within 30 minutes. Use exception monitoring when a specific property value in an incoming message indicates a failure condition. Use query monitoring when you want to alert on an aggregate condition — for example, more than 10 failed instances in the past hour. Use summary alerts when you want a scheduled digest of transaction activity rather than real-time alerts. See the individual rule articles for setup details: Duration monitoring, Exception monitoring, Query monitoring, Summary alerts. -
Can I apply multiple monitoring rules to the same transaction?
Yes. You can create any number of monitoring rules across any rule type for the same transaction. Each rule is evaluated independently on its own schedule or trigger condition. This is useful when you want both real-time exception alerts and a daily summary digest for the same business process, or when different stakeholders need alerts delivered through different escalation policies. -
What is an escalation policy, and how does it connect to a monitoring rule?
An escalation policy defines who gets notified, through which channel, and under what conditions when a monitoring rule triggers. Each monitoring rule is linked to one escalation policy. The policy specifies the notification channel (such as email, Teams, Slack, or PagerDuty), the escalation delay, and whether to escalate further if the alert is not acknowledged. Create escalation policies first under Managing escalation policies, then assign them to monitoring rules when you configure each rule. -
How do I set the right threshold for duration monitoring without generating too many false alerts?
Start by measuring the actual completion time of healthy transactions over a representative sample period — use the transaction instances view to review completed instance durations. Set the duration threshold at 1.5 to 2 times the typical completion time for your business process. This allows for normal variation while still catching genuine delays. Adjust the threshold after the first week of live monitoring based on the alert volume and the operational significance of each triggered alert. -
Can summary alerts be sent to multiple recipients or channels?
Yes. A summary alert uses an escalation policy for delivery, and an escalation policy can include multiple notification channels. To send a summary alert to multiple recipients or systems, configure the escalation policy with the required channels before assigning it to the summary alert rule. See Managing escalation policies for multi-channel configuration. -
How often do monitoring rules evaluate transaction data?
Duration monitoring and query monitoring run on a scheduled evaluation cycle managed by the BAM monitoring engine. The cycle interval is configured at the environment level during deployment. Exception monitoring is event-driven — it evaluates each incoming message as it arrives, without waiting for a scheduled cycle. Summary alerts run on the schedule you configure in the rule itself (for example, daily at 08:00 UTC). -
What happens to in-flight monitoring rules when I update a transaction's stage configuration?
Active monitoring rules are not automatically updated when you change a transaction's stages. Duration rules that reference a specific stage will continue to evaluate against that stage name — if the stage is renamed or removed, the rule will no longer find matching instances and will effectively stop triggering. After any stage configuration change, review all monitoring rules for the affected transaction and update stage references as needed to keep them aligned.