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.
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, "metric and log alerts on the few conditions that require action, wired to an action group that pages on-call" is the answer of someone who has carried a pager, not just built a dashboard.