Why bother
Azure posts incidents, maintenance and retirement notices to Service Health for the subscriptions it affects. Without alerts, that information sits in the portal. Two recent examples:
- The 30 September 2026 gateway incident (PIR 7Q30-010) affected ExpressRoute, VPN Gateway, Firewall and more in 33 regions.
- The 29 September 2026 Azure OpenAI / Foundry incident in Sweden Central (PIR 7QL5-Z50) caused request failures for about six hours.
Both reviews recommend Service Health alerts. Retirement notices (for example Azure OpenAI model retirements) also arrive as health advisories.
Event types
| Event type | What it contains | Who should get it |
|---|---|---|
| Service issue | Active incidents affecting your resources | On-call (page or chat) |
| Planned maintenance | Upcoming maintenance windows | Platform team, change board |
| Health advisories | Retirements, feature changes, required actions | Service owners, architects |
| Security advisory | Security-related notices | Security team |
Send them to different action groups. Mixing retirements into the paging channel trains people to ignore it.
1. Action groups
az monitor action-group create -g rg-monitoring -n ag-oncall \
--short-name oncall \
--action email oncall oncall@example.com \
--action webhook teams https://example.webhook.office.com/...
az monitor action-group create -g rg-monitoring -n ag-service-owners \
--short-name owners --action email owners platform-owners@example.com
2. Alert rules (Bicep)
resource incidents 'Microsoft.Insights/activityLogAlerts@2020-10-01' = {
name: 'sh-service-issues'
location: 'Global'
properties: {
scopes: [ subscription().id ]
condition: {
allOf: [
{ field: 'category', equals: 'ServiceHealth' }
{ field: 'properties.incidentType', equals: 'Incident' }
]
}
actions: { actionGroups: [ { actionGroupId: oncallAgId } ] }
enabled: true
}
}
resource advisories 'Microsoft.Insights/activityLogAlerts@2020-10-01' = {
name: 'sh-health-advisories'
location: 'Global'
properties: {
scopes: [ subscription().id ]
condition: {
allOf: [
{ field: 'category', equals: 'ServiceHealth' }
{ anyOf: [
{ field: 'properties.incidentType', equals: 'Informational' }
{ field: 'properties.incidentType', equals: 'ActionRequired' }
] }
]
}
actions: { actionGroups: [ { actionGroupId: ownersAgId } ] }
enabled: true
}
}
Add a third rule for Maintenance and a fourth for Security. You can narrow by service and region with extra conditions on properties.impactedServices[*].ServiceName and properties.impactedServices[*].ImpactedRegions[*].RegionName, but start broad. Missing an incident because the filter was too narrow is worse than a few extra notices.
Deploy the rules to every subscription, ideally through Azure Policy (DeployIfNotExists) or your landing-zone pipeline, so new subscriptions get them automatically.
3. Service names to remember
- Azure OpenAI and Foundry models: select Azure OpenAI Service. There's no separate "Microsoft Foundry" service in Service Health.
- Networking: ExpressRoute, VPN Gateway, Virtual WAN, Azure Firewall, Application Gateway, Azure Front Door.
4. Test
The portal's alert rule page lets you test an action group. Also check last month's activity log for Service Health events to see what you would have received:
az monitor activity-log list --offset 30d \
--query "[?category.value=='ServiceHealth'].{time:eventTimestamp, title:properties.title, type:properties.incidentType}" -o table
5. Resource Health for your own resources
Service Health says "the platform has a problem in this region". Resource Health says "this VM / gateway / database is unavailable". Add Resource Health alerts for critical resources (gateways, databases, firewalls) to the on-call action group as well.
Checklist
- Separate action groups for on-call, service owners and security
- Alerts for Incident, Maintenance, Informational/ActionRequired and Security
- Deployed to every subscription through policy or the landing zone
- Azure OpenAI Service included for model retirements
- Resource Health alerts on critical resources
- Action groups tested