Azure Monitor alerts explained: log alerts, action groups and the alert email

Alerts in Azure Monitor have three moving parts. The alert rule combines a scope (the resources), a signal (a metric, a log query, an activity log event) and a condition. The alert is the record created when the condition is met, kept for 30 days on the Alerts page. The action group is the reusable list of who gets told and what gets called. Alert processing rules sit on top and can add or suppress action groups for alerts as they fire.

What the alert email means

Microsoft doesn’t publish its default email template, but every notification is built from the common alert schema, so the email can only say what the schema holds. Read it field by field:

Enable the common alert schema on each email action for the detailed template; it adds links to the alert in the portal and to the affected resource. Custom properties defined on the rule never appear in emails, SMS or push notifications, only in webhook, Logic Apps, function and runbook payloads. In a resolved log search alert, the metric value is left blank by design, because resolution is based on elapsed time, not on a measurement.

The email comes from azure-noreply@microsoft.com, azureemail-noreply@microsoft.com or alerts-noreply@mail.windowsazure.com; allow all three in your mail filters. Because the sender is always Microsoft, the address proves nothing about who created the rule. Anyone who adds your address to an action group in their own subscription can send you alerts whose name and description they wrote; you get a notice when you’re added, and new addresses are asked to confirm a one-time passcode. Treat an alert from a subscription you don’t recognise as suspect: don’t call numbers or follow links in its description. Unsubscribing removes you from that action group.

Metric alerts vs log search alerts

Application Insights standard metrics are pre-aggregated and not affected by sampling, which makes them the safest alert signal. Availability tests come with their own alert rule, covered in certificate expiration and availability tests. Log search alerts measure either the number of rows a query returns or a numeric column, and can split results by up to six dimensions. Microsoft notes they’re weaker at detecting a lack of data, such as a missing heartbeat; that’s a job for metric alerts.

Action groups

An action group holds notifications (email, email to an Azure Resource Manager role, SMS, Azure mobile app push, voice) and actions (webhook, secure webhook, Logic Apps, Azure Functions, Automation runbook, Event Hubs, ITSM). A rule can use up to five action groups, they run concurrently, and one group can serve many rules. Use Test on the action group before you rely on it.

Rate limits apply per recipient across all subscriptions: no more than 100 emails an hour to one address per region, one SMS and one voice call every five minutes, and 100 notifications every five minutes per alert rule per region. When email is throttled, Microsoft sends a notice saying so. For high volumes, Microsoft points to webhooks, Logic Apps, functions or runbooks instead. Posting to Microsoft Teams goes through a Logic App, because a plain webhook can’t reshape the payload.

Create a log search alert over KQL, step by step

This rule fires when any operation’s failure rate passes 5% over five minutes, with at least 20 requests, so a single failed call at 3 a.m. doesn’t page anyone.

1. Open the Application Insights resource, select Alerts > + Create > Alert rule. The scope is set to the resource.
2. On Condition, choose Custom log search and paste the query below. Select Run, then Continue Editing Alert.
3. Under Measurement, set Measure to failurePct, Aggregation type to Maximum, and Aggregation granularity to 5 minutes.
4. Under Split by dimensions, add operation_Name so each operation alerts separately. Avoid IDs, timestamps or other high-cardinality columns: each combination is a separate alert and a separate charge.
5. Under Alert logic, choose a static threshold, Greater than, 5, and Frequency of evaluation 5 minutes.
6. Under Advanced options, set Number of violations to 2 and Evaluation period to 15 minutes (three 5-minute windows), so a single bad window doesn’t fire.
7. On Actions, pick an action group and, optionally, a custom Email subject.
8. On Details, set the severity, a clear name and a description that tells the reader what to do. Leave Automatically resolve alerts on. Prefer a managed identity, and give it Reader on the resource and its workspace.
9. Review + create.

The query, written for the Application Insights resource (in a workspace, use AppRequests, ItemCount and Success):

requests
| summarize total = sum(itemCount),
            failed = sumif(itemCount, tostring(success) =~ "false")
  by bin(timestamp, 5m), operation_Name
| where total >= 20
| extend failurePct = round(100.0 * failed / total, 1)

No time filter is needed: the rule sets the query’s time range from the granularity and number of periods, and caps it at two days. Keep the bin(timestamp, …) column, because Number of violations needs a datetime column in the results. The failed requests by result code query is the natural follow-up when the alert fires, and the KQL builder writes the itemCount weighting for you.

The same rule as Bicep, for repeatable deployments (API version 2023-12-01 or later supports the custom subject):

resource failureRate 'Microsoft.Insights/scheduledQueryRules@2023-12-01' = {
  name: 'orders-api-failure-rate'
  location: location
  kind: 'LogAlert'
  properties: {
    displayName: 'orders-api failure rate over 5%'
    severity: 2
    enabled: true
    scopes: [ appInsights.id ]
    evaluationFrequency: 'PT5M'
    windowSize: 'PT5M'
    autoMitigate: true
    criteria: {
      allOf: [
        {
          query: loadTextContent('failure-rate.kql')
          timeAggregation: 'Maximum'
          metricMeasureColumn: 'failurePct'
          dimensions: [ { name: 'operation_Name', operator: 'Include', values: [ '*' ] } ]
          operator: 'GreaterThan'
          threshold: 5
          failingPeriods: { numberOfEvaluationPeriods: 3, minFailingPeriodsToAlert: 2 }
        }
      ]
    }
    actions: {
      actionGroups: [ actionGroup.id ]
      actionProperties: { 'Email.Subject': 'Failure rate high on orders-api' }
    }
  }
}

What alerts cost

Microsoft bills metric alerts per monitored time series and log search alerts by evaluation frequency, plus each time series a split creates beyond the first. Activity log, service health and resource health alerts are free, and disabled rules cost nothing. East US list prices from the Azure Retail Prices API, per month:

The rule above, split across 30 operations at 5 minutes, costs $1.50 + 29 × $0.15 = $5.85 a month; at 1-minute frequency it would be $3.00 + 29 × $0.30 = $11.70. One-minute rules also reject queries that use search, union, take or ingestion_time(), and a subscription can have only 100 of them among its 5,000 log alert rules. Microsoft notes no additional cost for querying data already in the workspace; Basic-plan tables used by simple log search alerts add a charge for data scanned.

Classic SDK 2.x

How the app is instrumented changes what an alert sees. The 2.x SDKs sample adaptively by default, so a log alert that counts rows with count() undercounts; weight with itemCount as above, or alert on standard metrics, which are pre-aggregated before sampling. Custom metrics sent with GetMetric() are never sampled and appear in metric alerts under the Application Insights namespace; see custom metrics. Smart detection still runs on top: Failure Anomalies and Performance Anomalies email by default and can be migrated to regular alert rules with action groups.

Today: SDK 3.x and the Microsoft OpenTelemetry Distro

SDK 3.x and the Distro sample at five traces per second by default, and trace-based log sampling drops logs from unsampled traces, so the same itemCount rule applies to requests, dependencies, traces and exceptions. The Distro’s Azure Monitor integration, like the Java agent, still emits Application Insights standard metrics, so failed-request and response-time metric alerts keep working after a migration. OpenTelemetry metrics land in customMetrics and in the azure.applicationinsights metric namespace; Microsoft also has query-based metric alerts over OpenTelemetry and Prometheus metrics in preview. See sampling explained for the rates.

Fix noisy alerts

• Make rules stateful. A stateless rule notifies on every evaluation while the condition holds; a stateful one fires once and resolves once.
• Require persistence. Two violations out of three periods filters single spikes; dynamic thresholds help when no fixed number fits.
• Add a volume floor. Percentages on tiny counts are noise; where total >= 20 removes them.
• Mute actions for a period after firing when one incident shouldn’t page every five minutes.
• Suppress, don’t disable, during maintenance. An alert processing rule with a schedule removes action groups from alerts in a scope; the alerts still appear in the portal, and the rule can take up to 30 minutes to apply.
• Remove duplicates. Azure doesn’t check for overlapping rules, and an address in two action groups gets two emails.
• Choose the right signal. If log latency causes late or false alerts, move the condition to a metric alert.

Troubleshooting