Alert configuration

Overview

Alerts in Turbo360 notify the right people when a monitoring rule condition is met. The effectiveness of alerts depends not just on whether rules are configured, but on how notification channels, routing logic, escalation paths, and alert grouping are set up.

Poorly configured alerts produce noise, delay response, or fail to reach the right person. This article describes the patterns that produce a well-configured, reliable alerting setup for Business Applications.

Business value

Effective alert configuration ensures that the correct team or individual is notified at the right time with enough context to act. It reduces alert fatigue by eliminating low-signal notifications and ensures that critical conditions are never silently missed due to routing gaps.

How it works

When a monitoring rule condition is met in Turbo360, an alert is generated for the affected Business Application. Turbo360 routes the alert based on the notification channels and escalation policies configured for that application. Alerts can be delivered via email, Microsoft Teams, webhooks, or SMS, depending on your organization's integration configuration.

The alert includes the Business Application name, the triggered rule, the affected resource, and a timestamp. From the alert, recipients can navigate directly to the Business Application's alert history and monitoring dashboard.

1. Route alerts to role-appropriate channels first

Alerts should reach the team or individual responsible for the affected workflow — not a shared inbox that no one monitors closely. Configure notification channels that map to how your team actually operates:

• Microsoft Teams — suitable for team-level awareness, warning-severity alerts, and conditions that need collective visibility.
• Email — suitable for individuals who own a specific resource or workflow, and for escalation chains.
• Webhook — suitable for integration with external incident management tools (PagerDuty, Opsgenie, ServiceNow).
• SMS — suitable for high-severity, out-of-hours escalation where a recipient may not be monitoring Teams or email.

Avoid routing all alerts to a single shared email address or Teams channel. Diffuse ownership reduces response speed.

2. Match notification channel to alert severity

Not every alert needs every channel. Apply channel selection by severity:

Keeping warning-level alerts out of SMS and phone escalation reduces fatigue and preserves urgency for genuinely critical conditions.

3. Use escalation policies for every critical alert path

An escalation policy defines what happens if an alert is not acknowledged within a defined window. Every critical monitoring rule in a production Business Application should have an escalation policy that:

1. Notifies the primary on-call contact immediately.
2. Escalates to a secondary contact after a configurable window (e.g. 15 minutes).
3. Includes a final fallback recipient who is always reachable.

Do not rely on a single-recipient notification for production critical alerts. If that recipient is unavailable, the alert goes unresponded.

4. Avoid over-alerting on transient conditions

Many Azure resources experience brief, transient state changes during normal operation — a Logic App retrying after a throttle, a Service Bus briefly queuing messages during load. Alerting on every transient event generates noise that trains teams to deprioritize notifications.

Mitigate this by:

• Setting a minimum consecutive breach count before a rule fires (where supported).
• Using evaluation windows that reflect a meaningful observation period (e.g. 5 or 10 minutes) rather than point-in-time checks for volatile metrics.
• Treating the first occurrence of a condition as a warning, and sustained occurrence as critical.

5. Include diagnostic context in alert routing

Turbo360 alerts include the Business Application name, affected resource, and rule name. Ensure your monitoring rules and Business Applications are named clearly enough that an alert notification alone gives the recipient enough context to begin triage without needing to log in first.

A rule named Logic App – Failed runs on a Business Application named Order Processing – Production gives the on-call engineer immediate context. A rule named Rule 1 on BA-04 does not.

6. Test alert delivery before an incident occurs

After configuring notification channels and escalation policies, test the full alert path:

1. Trigger a test condition that will fire the monitoring rule.
2. Confirm that the notification is delivered to the correct channel and recipient.
3. Confirm that the escalation policy activates correctly if the alert is left unacknowledged.

Do not wait for a real incident to discover that a notification channel is misconfigured or that an escalation contact is no longer reachable.

7. Review alert configuration after team or environment changes

Alert routing becomes stale when team membership, on-call rotation, or escalation chains change and the Turbo360 configuration is not updated. After any of the following, review and update alert configuration:

• On-call rotation or ownership changes.
• Team restructuring.
• Decommissioning of a Business Application or resource.
• Changes to integration credentials (e.g. Teams webhook tokens, SMS provider settings).

Example scenario

A team manages a production invoice generation workflow. They configure alerts as follows:

• All monitoring rules are assigned to an escalation policy named Invoice – Production On-Call.
• Warning-level alerts route to the team's Microsoft Teams channel for shared visibility.
• Critical alerts route to the on-call engineer's email address immediately and to the same Teams channel.
• If the critical alert is not acknowledged within 20 minutes, the escalation policy sends an SMS to the on-call engineer and emails the team lead.
• Monitoring rule names follow the convention [Resource type] – [Condition] (e.g. Logic App – Failed runs, Service Bus – Dead-letter threshold exceeded).

After initial setup, the team tests the full alert path by manually triggering a Logic App failure, confirming delivery to Teams and email, then leaving the alert unacknowledged to validate SMS escalation fires at the 20-minute mark.

Limitations

• Notification channel availability depends on your Turbo360 organization's integration configuration. SMS and webhook channels require prior setup by an organization administrator.
• Escalation policy acknowledgement windows are measured from the time the alert is generated, not from when it is delivered. Network delivery delays may reduce the effective acknowledgement window.
• Alert delivery to Microsoft Teams requires an active incoming webhook integration. If the webhook token expires or the Teams channel is deleted, alerts will fail silently unless a fallback channel is configured.

Troubleshooting

1. Alert was triggered but no notification was received
   Cause: The notification channel is misconfigured, the integration credential has expired, or the channel is not assigned to the monitoring rule's escalation policy.
   Fix: Verify the notification channel configuration in Turbo360. Confirm that the escalation policy is correctly assigned to the Business Application. Test the channel by triggering a test notification.

2. Escalation policy did not fire after the acknowledgement window elapsed
   Cause: No escalation policy is assigned to the Business Application, the alert was acknowledged before the window elapsed, or the escalation contact list is empty.
   Fix: Review the escalation policy assigned to the Business Application. Confirm the acknowledgement window value and verify that at least one escalation contact is configured.

3. Alert notifications are arriving but contain no useful context
   Cause: Monitoring rules or Business Application names are too generic to convey the failure context.
   Fix: Rename monitoring rules to follow a descriptive convention (e.g. [Resource type] – [Condition]) and ensure Business Application names include workload and environment identifiers.

4. Too many alerts are firing for a production Business Application
   Cause: Monitoring rules are set to fire on transient conditions or at thresholds that do not represent genuine deviation.
   Fix: Review rule thresholds and adjust them to reflect observed baselines. Where the monitoring rule supports it, configure the rule to fire only after the threshold is breached across multiple consecutive monitoring cycles — this prevents a single transient spike from triggering an alert. Reclassify low-signal conditions from critical to warning.

5. A Teams channel stopped receiving alert notifications
   Cause: The Microsoft Teams incoming webhook URL has expired or the channel has been deleted.
   Fix: Regenerate the webhook URL in Microsoft Teams and update the notification channel configuration in Turbo360. Test delivery after updating.

Related articles

• Alert history
• Managing alert incidents
• Escalation policies
• Rules configuration
• Monitoring strategy