Alerting

What it is

Alerting is the practice of proactively notifying the right people when monitored telemetry crosses a defined threshold or condition, so issues are surfaced and acted on without someone watching a dashboard. In Azure it is built on Azure Monitor alerts — rules that evaluate signals and trigger an action group (email, SMS, webhook, ITSM, VM, etc.).

Why it exists

Telemetry sitting in a store is passive — a problem only surfaces when someone happens to look. Alerting exists to make monitoring event-driven: the system actively tells you “this is broken / degrading” so you can respond quickly, minimizing outages and user impact.

Key ideas

• An alert rule = signal + condition + action:
  • Signal — metric (metric alert), log query (KQL), activity-log event, or App Insights condition.
  • Condition/logic — e.g. CPU > 85%, error count > 5, URL unavailable.
  • Action group — who/how to notify (email, SMS, push, webhook/automation, ITSM).
• Alerts have severity levels and can include dynamic thresholds (anomaly-based) in addition to static thresholds.
• Managed alerts keep you proactive: they’re the trigger side of a feedback loop.

Exam notes

• Know the alert rule anatomy: rule → signal + condition → action group.
• Metric alert = numeric threshold on a metric; log-alert = condition evaluated against a KQL query result.
• An action group centralizes notification channels and is reused across many alert rules.
• The exam pairs alerts with monitoring: alerts turn raw telemetry into notifications that drive response and the feedback loop.
• Synthetic/availability test failures are a common alert source (App Insights).

Related

azure-monitor · metric-alert · application-insights · action-group · telemetry · synthetic-testing · feedback-loop

📘 Source: Microsoft Learn — Alerting