Azure alerts and action groups: turning telemetry into a page
Collecting telemetry is worthless if nobody looks until a customer complains. Alerts close that gap — an alert rule watches the data, and an action group decides who gets told and what happens next.
New to cloud? CAMPUX is a free, build-first course. Start here →
You wired up monitoring, logs are flowing, dashboards are pretty. And you still find out about outages from an angry email, because nobody stares at a dashboard at 3am. Azure Monitor alerts fix that. Microsoft's framing is the whole point: alerts "help you detect and address issues before users notice them by proactively notifying you when Azure Monitor data indicates there might be a problem." The system watches so you do not have to, and taps someone on the shoulder when it matters. It works through two pieces that are worth keeping straight.
The alert rule: what to watch, and when to worry
An alert rule is the "if." It combines three things: the resource to watch, the signal from it (a metric or a log query), and the condition that means trouble. When the signal meets the condition, the rule fires an alert and kicks off its action. The signal can come from anywhere in the Azure Monitor data platform, which gives you a few alert types:
- Metric alerts evaluate numeric metrics at regular intervals — CPU over 90%, queue depth climbing — and support multiple conditions and dynamic thresholds.
- Log search alerts run a Log Analytics (KQL) query on a schedule, so you can alert on anything you can query — a spike in a specific error, a pattern across services.
- Activity log alerts fire on control-plane events — a resource deleted, a service-health notice for your region.
Metric for "is this number wrong?", log for "does this query find something?", activity for "did something happen to the resource itself?"
The action group: who gets told, and what runs
An alert that fires into the void is useless. The action group is the "then" — a reusable bundle of notifications and actions that the alert triggers. It can:
- Notify — email, SMS, and push notifications to the right people.
- Act — call a webhook or secure webhook, run an Azure Function or Automation runbook, kick off a Logic App, or open an ITSM incident.
Because it is reusable, you define "page the on-call team" once as an action group and attach it to every rule that should page them. Splitting the "what to watch" (rule) from the "who to tell" (action group) is what lets you manage alerting at scale without copying contact lists into fifty places.
The rule decides when to worry. The action group decides who finds out. Keep them separate and both stay manageable.
The failure mode is not too few alerts — it is too many. Forty noisy alerts that fire constantly train a team to mute the whole channel, so the one that matters is lost in the din. Three alerts that fire only on real, actionable problems get answered. When you set alerts, ask of each one: "if this fires at 3am, is there something a human should do right now?" If not, it is a dashboard metric, not an alert. Signal over noise is the entire craft.
Stateful vs stateless, briefly
One practical detail worth knowing: alerts can be stateful or stateless. A stateless alert fires every time the condition is met, again and again. A stateful alert fires once, then stays quiet until the underlying problem resolves — and sends a "resolved" notification when it clears. Stateful is usually what you want for incident-style alerts: one page when it breaks, one all-clear when it recovers, not a pager buzzing every minute in between.
The takeaway
Turn your telemetry into action with two moving parts: alert rules that watch a signal and fire on a real condition, and action groups that reliably notify a human or run a fix. Reach for metric, log, or activity alerts depending on whether you are watching a number, a query, or an event — and be ruthless about keeping the set small and actionable. When an interviewer asks how you would know your system is failing before your customers do, the crisp reply is metric and log alerts on the few conditions that require action, wired to an action group that pages on-call. Say that and you sound like you have carried the pager, not just admired the dashboard.
Questions people also ask
What is the difference between an alert rule and an action group in Azure?
An alert rule is the condition: it watches a resource's metric, log query, or activity event and fires when that condition is met. An action group is what happens next, a reusable set of notifications and actions the rule triggers. One decides when to worry, the other decides who finds out.
What is an action group in Azure Monitor?
An action group is a reusable bundle of notifications and actions that an alert rule triggers when it fires. It can email, text, or push-notify the right people, and it can call a webhook, run a Function or Automation runbook, kick off a Logic App, or open an ITSM incident. Define it once, attach it to every rule that should page the same team.
What is the difference between a metric alert and a log alert in Azure?
A metric alert evaluates a numeric metric at regular intervals, CPU over 90%, queue depth climbing, and answers "is this number wrong?" A log search alert runs a Log Analytics KQL query on a schedule and answers "does this query find something?" Metric alerts are faster and simpler; log alerts can check almost anything you can query.
Can one action group be used by multiple alert rules?
Yes. That is the point of splitting rules from action groups. You define "page the on-call team" once as an action group, then attach it to every alert rule that should trigger that response, instead of copying a contact list into fifty separate rules.
What is the difference between stateful and stateless alerts in Azure Monitor?
A stateless alert fires every time its condition is met, again and again, for as long as the problem persists. A stateful alert fires once, stays quiet while the problem continues, then sends a resolved notification when it clears. Stateful suits incident-style alerts: one page when it breaks, one all-clear when it recovers.