Building Azure Monitor Alerts and Action Groups

Overview and What You Will Learn

In this lab, you will create an Action Group defining who gets notified, then build an alert rule that watches a VM's CPU metric and triggers that Action Group once a threshold is crossed - the complete path from a raw metric to an actual notification landing in someone's inbox.

Why This Matters in Production

A support engineer at CRED gets paged at 2 AM because a production database ran out of disk space - an event a properly configured Azure Monitor alert would have flagged hours earlier, giving the team time to react before customers noticed anything. The gap between "the metric existed" and "someone was actually notified in time" is exactly what Action Groups and alert rules close.

Core Principles

Azure Monitor alerts have two separate parts that must both be configured correctly: the condition that triggers the alert, and the Action Group defining what happens once it does.

An alert rule with no Action Group attached will still show up in the Azure Portal's alert history, but nobody will actually be notified - the Action Group is what makes an alert actionable rather than just a passive log entry.

Detailed Step-by-Step Practical Lab

1. Create a Resource Group and a test VM to monitor:

2. Create an Action Group defining an email recipient to notify:

3. Create an alert rule watching CPU usage, attached to that Action Group:

4. Confirm the alert rule was created and check its current status:

5. Simulate load on the VM (using a tool like stress installed via SSH) to trigger the alert, then check the Action Group's configured email address for the notification.

6. Review the alert's history in the Portal or via CLI to confirm it fired as expected:

7. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Creating an alert rule but forgetting to attach an Action Group, or attaching one with an outdated email address nobody actually monitors. The alert will still technically "fire" and appear in Azure's own alert history, but if nobody is actually notified in a way they'll see promptly, the alert provides no real protection.

Tip

Alert on the metric that predicts a problem, not only the metric that confirms one already happened. A disk-space-approaching-full alert gives you time to react before an outage; an "application crashed" alert means the outage has already started.

• Set the evaluation window and frequency thoughtfully. A window too short can trigger false alarms from brief, harmless spikes; a window too long delays a genuine alert past the point where it's still useful.
• Route different severities to different Action Groups. A critical production outage alert going to an on-call phone number is a different urgency than a minor cost-threshold warning going to a shared team email - treating every alert identically dilutes the ones that actually need immediate attention.

Quick Reference & Troubleshooting Commands