Your First Alert Rule

Alerts are how Azure Monitor turns passive data into active notifications. Instead of staring at dashboards, you define conditions and let Azure tell you when something goes wrong — via email, SMS, webhook, or automated action.

Why Alerts Matter

Without alerts, monitoring is reactive. You only discover problems when users complain. Alerts shift you to proactive operations:

• Catch CPU spikes before they cause downtime
• Detect error rate increases within minutes
• Respond to queue buildup before messages expire
• Get notified of security-relevant activity log events

Alert Components

Every alert rule has four parts:

Understanding Alert Severity Levels

Alert States

Metric alerts auto-resolve when the condition is no longer true. Log alerts can be configured to auto-resolve or require manual closure.

Step-by-Step: Create an Action Group

An action group defines what happens when an alert fires. Create it first, then reference it in alert rules.

Portal

1. Go to Azure Monitor → Alerts → Action groups
2. Click + Create
3. Fill in: Subscription, Resource Group, Name, Display Name
4. Under Notifications, add: Type = "Email/SMS/Push/Voice", enter email address
5. Optionally add Actions (webhook, Azure Function, Logic App, ITSM)
6. Click Review + Create

CLI

# Create an action group with email notification
az monitor action-group create \
  --resource-group myRG \
  --name "ops-team-email" \
  --short-name "OpsEmail" \
  --action email ops-lead ops-lead@company.com

# Create an action group with email AND webhook
az monitor action-group create \
  --resource-group myRG \
  --name "ops-team-full" \
  --short-name "OpsFull" \
  --action email ops-lead ops-lead@company.com \
  --action webhook slack-hook "https://hooks.slack.com/services/XXX/YYY/ZZZ"

# Verify the action group
az monitor action-group show \
  --resource-group myRG \
  --name "ops-team-email" \
  --output table

Step-by-Step: Create a Metric Alert (CPU > 80%)

Portal

1. Go to Azure Monitor → Alerts → + Create → Alert rule
2. Scope: Select your App Service Plan
3. Condition: Select signal "CPU Percentage"
   • Aggregation type: Average
   • Operator: Greater than
   • Threshold: 80
   • Check every: 1 minute
   • Lookback period: 5 minutes
4. Actions: Select your action group ("ops-team-email")
5. Details: Name = "High CPU Alert", Severity = 2 (Warning)
6. Click Review + Create

CLI

# Create a metric alert for CPU > 80% on an App Service Plan
az monitor metrics alert create \
  --resource-group myRG \
  --name "high-cpu-alert" \
  --description "Alert when CPU exceeds 80% for 5 minutes" \
  --severity 2 \
  --scopes "/subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Web/serverFarms/myPlan" \
  --condition "avg CpuPercentage > 80" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action "/subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Insights/actionGroups/ops-team-email"

# Create an alert for HTTP 5xx errors > 10 in 5 minutes
az monitor metrics alert create \
  --resource-group myRG \
  --name "http-5xx-alert" \
  --description "Alert on server errors" \
  --severity 1 \
  --scopes "/subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Web/sites/myApp" \
  --condition "total Http5xx > 10" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action "/subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Insights/actionGroups/ops-team-email"

# List all alert rules in a resource group
az monitor metrics alert list --resource-group myRG --output table

Testing Your Alert

1. For CPU alerts — Run a load test or stress tool against your app to spike CPU
2. For error alerts — Temporarily introduce a bug or hit a non-existent endpoint to generate 5xx errors
3. For queue alerts — Send messages without running the consumer
4. Check email — Notifications arrive within 1–5 minutes of the condition being met
5. Verify in portal — Go to Azure Monitor → Alerts to see fired alerts

Tip: Use the "Test action group" button in the portal to verify email delivery without waiting for a real alert.

Viewing Fired Alerts in Portal

1. Go to Azure Monitor → Alerts
2. See the summary: total alerts by severity
3. Click any severity to filter
4. Click an individual alert to see:
   • When it fired
   • The condition that triggered it
   • The resource affected
   • History (state changes)
5. Change state to "Acknowledged" when investigating, "Closed" when resolved

Common Alert Scenarios

Cost Considerations

Keep alert rules focused. 50 well-targeted rules cost less than $10/month and provide comprehensive coverage.

Common Mistakes

• Alert fatigue — Too many low-severity alerts that nobody acts on. Start with critical alerts only, then expand.
• Too-sensitive thresholds — CPU > 50% fires constantly. Use realistic thresholds based on your baseline.
• No action group — Creating an alert rule without an action group means alerts fire silently (visible only in portal).
• Forgetting auto-resolve — Metric alerts auto-resolve by default, but log alerts may not. Configure this explicitly.
• Not testing — Always test your action group to confirm emails arrive and webhooks fire.

Tips

• Start with 3–5 critical alerts per application, then add more as you learn your baseline.
• Use severity levels consistently across your team so everyone knows what requires immediate action.
• Combine metric alerts (fast, simple) with log alerts (complex, slower) for comprehensive coverage.
• Set up a shared mailbox or Slack channel for alerts — don't send to individual emails.

Key Takeaways

• Alerts turn monitoring data into actionable notifications — they're essential for proactive operations.
• Every alert needs: a signal, a condition, an action group, and a severity level.
• Create action groups first, then reference them in multiple alert rules.
• Metric alerts are cheap (~$0.10/month), fast (1-minute evaluation), and auto-resolve.
• Start with a few high-value alerts and expand — alert fatigue is worse than no alerts.
• Always test your action groups to confirm notifications are delivered.
• Use severity levels (0–4) consistently to communicate urgency across your team.