Azure Service Health Alerts: Admin Setup Guide

Azure Service Health alerts feel like a boring guardrail right up until they save a Friday afternoon. Azure has service issues, planned maintenance, health advisories and security advisories, and the difference between “we knew and responded” and “why is everyone messaging me?” is usually whether the right alert rule existed before the incident.

This guide covers what to monitor, how to scope alert rules, how to route action groups, and how to keep the signal useful rather than noisy.

What Azure Service Health alerts tell you

Azure Service Health is a set of three related views:

• Azure status: a broad public view of service problems across regions.
• Service Health: a personalized view of service issues, planned maintenance, health advisories and security advisories affecting the subscriptions, services, regions or tenants you choose.
• Resource Health: the current and past health of individual resources such as a VM, web app or database.

Service Health alerts are built on service notifications in the Azure activity log. They aren’t Resource Health alerts for a specific resource. Use both; neither replaces the other.

Step 1: Create a baseline alert

In the portal, open Service Health > Health alerts and create a Service Health alert. You can scope it by subscription, tenant, service, region and event type. For the first pass, go deliberately broad:

• Scope: production subscriptions, or the management subscription that owns alerting.
• Services and regions: all.
• Event types: service issues, planned maintenance, health advisories and security advisories.
• Action group: a monitored operations channel plus the mailbox or ITSM route your team actually checks.

Microsoft notes that selecting all services and regions doesn’t flood your inbox with every Azure event; alerts fire for events affecting regions where your services run. Broad coverage is usually safer than narrow filters that silently miss a region someone added during a rushed deployment. Start broad, route intelligently, and tighten only once you have real alert history.

Step 2: Design action groups before the outage

Action groups define who is notified and what runs when an alert fires: email, SMS, voice, push, webhooks, Azure Functions and other automation. They’re reusable across rules. Avoid sending everything to one mailbox and hoping someone reads it.

Service Health alerts are supported in public clouds in the global region, and their action groups should be set to Global. Bake that into your infrastructure-as-code module so nobody has to remember it at 1 a.m.

Step 3: Separate paging from ticketing

• Immediate layer: service issues and selected security advisories go to on-call or an operations bridge.
• Work management layer: maintenance and advisories go to a queue where owners assess impact and schedule changes.

Not every event deserves an emergency call, but every relevant event deserves an owner. If everything pages the same way, people learn to ignore it.

Step 4: Cover tenants and subscriptions deliberately

Azure Resource Graph queries can identify the subscriptions, regions and services your alerting design should cover.

Step 5: Document the incident response path

• Triage: does the affected service, region or tenant map to production workloads?
• Correlate: check Resource Health and application monitoring for customer impact.
• Communicate: share what’s known, what isn’t, and when the next update is due.
• Mitigate: fail over, throttle, pause deployments or apply documented workarounds.
• Review: update runbooks, alert scopes and ownership afterwards.

Step 6: Test without waiting for an outage

• Verify the action group reaches the right mailbox, channel, webhook or ITSM endpoint.
• Confirm owners can access Service Health, the affected subscriptions and Resource Health.
• Run a tabletop exercise using a past notification or a fictional regional issue.
• Check that maintenance notices create review tasks.
• Review role-based email recipients, which change when role assignments change.

Common Azure Service Health alerts mistakes

• Over-filtering regions, so a new deployment region isn’t covered.
• One action group for everything, mixing urgency levels and owners.
• Ignoring Resource Health, which diagnoses individual resource availability.
• No runbook. An alert without a response path is just a nervous email.

Governance checklist

1. Create a broad baseline alert for production subscriptions.
2. Use a Global action group for Service Health routing.
3. Separate urgent incident routing from maintenance and advisory workflows.
4. Include security stakeholders for security advisories.
5. Document triage across Service Health, Resource Health, app monitoring and communications.
6. Review recipients, role-based notifications and webhooks quarterly.
7. After a real event, update scopes and runbooks.

Azure Service Health alerts should be part of how your cloud team operates, not a decorative checkbox. Pair them with an Azure diagnostic settings policy so the logs are there when an alert fires, and with the Azure DNS Private Resolver runbook for regional resilience planning.

Last reviewed: October 2026

Sources

• What is Azure Service Health? (Microsoft Learn)
• Create Service Health alerts (Microsoft Learn)
• Action groups in Azure Monitor (Microsoft Learn)
• Azure Resource Health overview (Microsoft Learn)
• Azure status page (Microsoft)