Azure Service Health alerts are one of those admin guardrails that feel boring right up until they save your Friday afternoon. Azure can have service issues, planned maintenance, health advisories, and security advisories. The difference between “we knew and responded” and “why is everyone Slacking me?” is usually whether the right alert rule existed before the incident.
This guide walks through a practical setup for outage-ready Azure Service Health alerts: what to monitor, how to scope alert rules, how to route action groups, and how to keep the signal useful instead of creating yet another notification confetti cannon. The monkey likes bananas. The monkey does not like alert spam. 🐒
Set broad Service Health coverage, then route by urgency.
- Best first alert: all services, all regions, all critical event types, routed to a monitored admin channel.
- Best mature pattern: separate action groups for incidents, maintenance, advisory-only notices, and security-sensitive notifications.
- Best governance habit: review alert owners quarterly. Nothing says “enterprise-ready” like outage emails going to someone who left in 2022.
What Azure Service Health alerts actually tell you
Microsoft describes Azure Service Health as a set of experiences for understanding the health of Azure services and resources. It includes three related views:
- Azure status gives a broad public view of service problems across Azure regions.
- Service Health gives a personalized view of service issues, planned maintenance, health advisories, and security advisories that may affect the subscriptions, services, regions, or tenant directories you choose.
- Resource Health helps diagnose the current and past health of individual resources such as a virtual machine, web app, or database.
That distinction matters. Azure Service Health alerts are built for Azure service notifications stored in the Azure activity log. They are not the same thing as Resource Health alerts for a specific VM, App Service, or database. Use both, but do not expect one to replace the other.
| Need | Use | Typical audience |
|---|---|---|
| Is Azure having a broad incident? | Azure status | Executives, public status checks, incident managers |
| Will this Azure incident or maintenance affect our subscriptions? | Azure Service Health | Cloud admins, platform teams, service owners |
| Is this specific resource healthy? | Azure Resource Health | App owners, SREs, support teams |
Step 1: Create a baseline Azure Service Health alert
In the Azure portal, open Service Health, go to Health alerts, and create a Service Health alert. Microsoft’s portal flow lets you configure the alert by scope, affected subscriptions, tenant directories, services, regions, and event types.
For the first pass, I usually recommend a deliberately broad baseline alert:
- Scope: production subscriptions or the management subscription that owns alerting resources.
- Services: all services.
- Regions: all regions.
- Event types: service issues, planned maintenance, health advisories, and security advisories.
- Action group: a monitored cloud operations channel, plus the mailbox or ITSM route your team actually checks.
Microsoft’s Service Health alert documentation includes a helpful tip: selecting all services and all regions does not mean every Azure event on Earth lands in your inbox. Service Health triggers alerts when events affect the regions where your services are running. Translation: broad coverage is usually safer than hyper-specific filters that silently miss the one region someone added during a rushed deployment.
SharePoint Monkey rule of thumb
Start broad, route intelligently, then tighten only after you have real alert history. Prematurely narrow filters are where outage awareness goes to take a little nap.
Step 2: Design action groups before the outage
Azure Monitor action groups define who is notified and what actions run when an alert fires. Microsoft documents support for notification types such as email, SMS, voice, push notifications, webhooks, Azure Functions, and other automation-friendly actions. Action groups can also be reused across multiple alert rules.
For Service Health alerts, avoid the classic “send everything to one mailbox and hope” pattern. It works beautifully until nobody owns the mailbox, the mailbox is full, or the one person who reads it is on a beach with heroic dedication to airplane mode.
| Event type | Suggested routing | Why |
|---|---|---|
| Service issues | On-call channel, incident mailbox, ITSM/webhook if used | Potential live impact needs fast triage. |
| Planned maintenance | Platform team, service owners, change calendar process | Needs scheduling, dependency checks, and stakeholder comms. |
| Health advisories | Cloud operations backlog or weekly review | Often important but not always page-worthy. |
| Security advisories | Security operations plus cloud platform owners | Requires a separate escalation path and audit trail. |
One important Microsoft note: Service Health alerts are supported in public clouds within the global region, and action groups used for Service Health alerts should be set to Global. If you are standardizing alert resources with infrastructure as code, bake that into the module so nobody has to remember it at 1:00 AM.
Step 3: Split “wake someone up” from “make a ticket”
A strong Azure Service Health setup usually has at least two layers:
- Immediate notification layer: service issues and selected security advisories routed to an on-call channel or monitored operations bridge.
- Work management layer: planned maintenance and advisory items routed to a queue where owners can assess impact and schedule changes.
The separation matters because not every Service Health event deserves an emergency call, but every relevant event deserves an owner. If everything pages the same way, people will eventually train themselves to ignore the noise. Congratulations, you have invented a very expensive snooze button.
Step 4: Add tenant and subscription coverage deliberately
Service Health alerts can be scoped by affected subscription and tenant directory. For small environments, one alert rule across production subscriptions may be enough. Larger organizations should decide whether alerting is owned centrally, delegated to platform landing zones, or both.
| Model | Good fit | Watch-out |
|---|---|---|
| Central alerting subscription | Organizations with a cloud platform team and central incident process | Needs clear ownership for app-specific impact analysis. |
| Per landing zone | Business units with delegated Azure ownership | Can create inconsistent alert routing unless templates are standardized. |
| Hybrid | Central awareness plus local service ownership | Requires deduplication and a sane escalation matrix. |
If you already use Azure governance patterns, pair this with your inventory work. For example, our Azure Resource Graph guardrails can help identify subscriptions, regions, and services that should be represented in your alerting design.
Step 5: Document the incident response path
The alert is only the opening bell. Decide what happens next:
- Triage: confirm whether the affected service, region, or tenant directory maps to production workloads.
- Correlate: check Resource Health for affected resources and application monitoring for customer impact.
- Communicate: send stakeholder updates with what is known, what is unknown, and when the next update is expected.
- Mitigate: fail over, throttle, pause deployments, or apply documented workarounds where appropriate.
- Review: after the event, update runbooks, alert scopes, and ownership metadata.
Step 6: Test without pretending Azure is down
You generally cannot summon a real Azure platform incident on demand, which is probably for the best. Instead, test the pieces around the alert:
- Verify the action group sends to the right mailbox, channel, webhook, or ITSM endpoint.
- Confirm alert owners have access to Service Health, the affected subscriptions, and Resource Health.
- Run a tabletop exercise using a past Service Health notification or a fictional regional service issue.
- Check that planned maintenance notifications create review tasks rather than disappearing into inbox archaeology.
- Review who receives email via Azure Resource Manager roles; role-based recipients can change when assignments change.
Common Azure Service Health alerts mistakes
Someone deploys to a new region, but the alert rule still watches last year’s footprint. Start broad unless you have a strong reason not to.
Service issues, maintenance, and security advisories usually need different urgency and different owners.
Service Health tells you about Azure service notifications. Resource Health helps you diagnose individual resource availability.
An alert without a response path is just a nervous email with better branding.
A lightweight governance checklist
- Create a broad baseline Azure Service Health alert for production subscriptions.
- Use a Global action group for Service Health alert routing.
- Separate urgent incident routing from maintenance and advisory workflows.
- Include security stakeholders for security advisories.
- Document the triage path: Service Health, Resource Health, app monitoring, communications.
- Review recipients, role-based notifications, and webhooks quarterly.
- After a real event, update alert scopes and runbooks based on what actually happened.
That is the whole point: Azure Service Health alerts should not be a decorative checkbox. They should be part of the operating system for your cloud team. Set them up before the outage, make the routing humane, and let automation handle the tedious notification plumbing so humans can focus on the fun work — like actually fixing things.
Sources
- Microsoft Learn: What is Azure Service Health?
- Microsoft Learn: Create Service Health alerts for Azure service notifications
- Microsoft Learn: Create and manage action groups in Azure Monitor
- Microsoft Learn: Azure Resource Health overview
- Microsoft Azure Status page
Discover more from SharePoint Monkey
Subscribe to get the latest posts sent to your email.