Monitoring strategy

Overview

A monitoring strategy defines how you apply monitoring rules, profiles, escalation policies, and alert configuration across your Business Applications to ensure that failures are detected early, the right people are notified, and incidents are resolved quickly. Configuring rules ad hoc per resource leads to gaps and inconsistency; a deliberate strategy makes your monitoring setup maintainable and aligned with the operational needs of each application and environment.

This article describes the core concepts involved in Business Application monitoring and explains how to combine them into a coherent strategy.

Business value

A well-designed monitoring strategy reduces mean time to detect and mean time to respond for issues across your Azure estate. By applying consistent rule sets through monitoring profiles, routing alerts through escalation policies, and tuning thresholds to match your environment, your team avoids both alert fatigue and monitoring gaps. The result is a monitoring setup that surfaces real issues reliably while keeping operational noise low.

How it works

Business Application monitoring operates through four interconnected components: monitoring rules, monitoring profiles, escalation policies, and alert configuration. Each serves a distinct purpose, and an effective strategy requires each component to be configured with intent.

Monitoring rules

Monitoring rules define the conditions under which an alert is raised for an Azure resource. Turbo360 evaluates each rule at a configurable frequency and raises an alert when the condition is met. Five rule types are supported:

Availability status: monitors whether a resource is available or unavailable.
State: monitors a resource's operational state (for example, Enabled or Disabled).
Metric: monitors an Azure metric against a numeric threshold (for example, failed run count over a given window).
Query: evaluates the result of a Log Analytics or Azure Monitor query against a defined threshold.
API Endpoint: sends an HTTP request to a specified URL and checks the response status code or body.

Rules can be configured directly on individual resources (resource-level rules) or through reusable monitoring profiles. For resources that experience transient conditions during normal operation, such as a Logic App retrying after a throttle or a Service Bus briefly queuing during load, set a minimum consecutive breach count or use an appropriate evaluation window to avoid alerting on normal behaviour.

Monitoring profiles

A monitoring profile is a reusable collection of monitoring rules that you apply to multiple resources or Business Applications. Profiles separate rule authoring from rule application: you define the rule set once in the profile, then apply it wherever relevant. When you update the profile, the change propagates to every Business Application that uses it.

Use profiles when several resources share the same monitoring requirements, such as all Logic Apps in a production tier or all Service Bus namespaces across multiple Business Applications. Resource-level rules are appropriate for conditions specific to a single resource that would not apply elsewhere.

Escalation policies

An escalation policy controls what happens when an alert is not acknowledged. Each policy consists of one or more rules that fire in sequence, each targeting a notification channel or recipient. If the alert remains unacknowledged after the time threshold defined in a rule, Turbo360 escalates to the next rule.

Every critical monitoring rule in a production Business Application should have an escalation policy. A robust policy for production workloads typically follows this structure:

Notify the primary on-call contact or team channel immediately when the alert fires.
Escalate to a secondary contact after a defined window (for example, 15 minutes) if no acknowledgement is received.
Include a final fallback recipient who is reliably reachable, such as an SMS contact or a secondary email.

A single-recipient notification for critical alerts creates a coverage gap: if that recipient is unavailable, the alert goes unresponded. Escalation policies eliminate that gap.

Escalation stops only when the alert incident is acknowledged or closed in the Turbo360 application. Dismissing a notification in the external channel (for example, closing an email) does not stop escalation.

Alert configuration

Alert configuration covers how notifications are routed and what they contain. The following practices produce a reliable alerting setup:

Route alerts to the team responsible for the affected workflow. Avoid routing all alerts to a single shared inbox or Teams channel. Diffuse ownership slows response.
Match notification channels to alert severity. Warning-level alerts are suited to a Teams channel for collective awareness. Critical alerts warrant email to the on-call individual. Unacknowledged critical alerts should escalate to SMS. Keeping low-severity alerts out of high-urgency channels preserves the signal-to-noise ratio.
Name rules and Business Applications clearly. Turbo360 alerts include the Business Application name, the triggered rule, the affected resource, and a timestamp. A rule named Logic App – Failed runs on a Business Application named Order Processing – Production gives an on-call engineer immediate context. Opaque names slow triage.

Recommended approach

Building a monitoring strategy from scratch follows this sequence:

Define environments and tiers. Distinguish production from non-production Business Applications. Apply stricter rules, lower thresholds, and mandatory escalation policies to production. Non-production applications may use simpler rule sets or silent monitoring.
Create monitoring profiles for shared rule sets. Identify resource types that appear across multiple Business Applications and share common monitoring needs. Create a profile for each such group (for example, one profile for Logic Apps and one for Service Bus) and apply profiles to the relevant applications rather than configuring rules per resource.
Configure escalation policies before assigning them. Create escalation policies as reusable objects in Monitoring settings before wiring them to Business Applications or profiles. A production tier typically needs at least one policy with two or three escalation rules. Use the default policy for non-critical applications where guaranteed escalation is not required.
Start with silent monitoring. If notification channels are not yet configured, or if you want to observe rule behaviour before committing to a notification strategy, enable monitoring without configuring recipients. Turbo360 evaluates rules and updates resource health status at every cycle. This is useful for validating rule thresholds before alerts go live.
Tune thresholds after the first week. Alert fatigue is usually a sign that thresholds are too sensitive or that transient conditions are being captured. After the first week of live monitoring, review alert volume and the operational significance of each triggered alert, then adjust thresholds, evaluation windows, or consecutive breach requirements accordingly.

Troubleshooting

Escalation policy is not triggering after the defined window.
Cause: The escalation policy may not be linked to the correct monitoring rule or Business Application, or the escalation contact has not accepted their notification subscription.
Fix: Verify the escalation policy is assigned under the Business Application's monitoring settings. Confirm the escalation contact's notification channel preferences are active and correctly configured.
Monitoring rules are not raising alerts despite the threshold being met.
Cause: Monitoring may be disabled at the Business Application level, or the rule evaluation frequency has not elapsed since the threshold was first breached.
Fix: Check that monitoring is enabled from the Business Application Overview toggle. Confirm the rule is enabled under Monitoring settings and wait for at least one evaluation cycle to complete.
Alert notifications are delivered but not reaching the right team.
Cause: Notification channels are routed to a shared inbox or a channel that is not actively monitored by the responsible team.
Fix: Review the notification channel configuration in the escalation policy and redirect alerts to a channel owned by the team responsible for the affected workflow.
Monitoring profile rules are not applying to resources added after the profile was assigned.
Cause: Monitoring profiles in Business Applications apply to resources present at the time of assignment. Resources added later may require manual reconfiguration.
Fix: After adding new resources to the Business Application, open the monitoring settings and verify the profile is applied to the new resources. Reapply the profile if needed.
Thresholds tuned for production are generating excessive alerts in non-production environments.
Cause: The same monitoring profile or rule set has been applied across environments without environment-specific threshold adjustments.
Fix: Create separate monitoring profiles for production and non-production tiers with thresholds appropriate to each environment's expected behaviour. Apply the correct profile per environment.