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.

Key practices

Follow these practices in order when you build a monitoring strategy from scratch.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

Example scenario

A platform team supports an order processing workflow with a production Business Application named Order Processing – Production and a UAT copy named Order Processing – UAT. They start by treating the two tiers differently. Production gets stricter rules and mandatory escalation, and UAT uses simpler rule sets.

The team creates one monitoring profile for Logic Apps and one for Service Bus, and applies them to both applications instead of configuring rules resource by resource. For production, they create an escalation policy that notifies the on-call engineer immediately, escalates to a secondary contact after 15 minutes, and ends with an SMS fallback. UAT uses the default policy.

Before they add recipients, the team turns on monitoring silently and watches resource health for the first week. At the end of the week they review the alert volume, adjust the thresholds and consecutive breach counts that produced noise, and then switch on notifications.

Limitations

Escalation stops only when an alert incident is acknowledged or closed in Turbo360. Dismissing a notification in an external channel, such as closing an email, does not stop it.
A monitoring profile applies to the resources that were in the Business Application when you assigned it. Resources you add later may need the profile applied again.
With silent monitoring, Turbo360 evaluates rules and updates resource health at every cycle, but no one is notified until you configure recipients.