Azure Service Health has four alert types. You probably configured one.

Microsoft

Jul 15, 2026

Most startups I work with have Service Health alerts configured on at least one subscription. That part's fine. The problem is they usually have it set up for Service Issues only, on their main subscription, while they're running six or seven.

Service Issues is the "Azure is down" alert. You want it. But it's one of four notification types, and the other three are the ones that catch the problems you could have seen coming.

The four types

Azure Service Health sends four categories of alertable notifications. (The portal also shows a fifth category, Billing updates, but that one isn't available as an alert rule trigger.) Here's what each alertable type looks like in the portal:

Service Issues are outages and degraded performance happening right now. This is what most people set up. It tells you something is already broken.

Health Advisories are about changes coming to your services. API deprecations, model retirements, required configuration changes, feature removals. For AI startups running Azure OpenAI, this is where model version retirement notices show up. If you're not subscribed, you find out when your inference calls start returning 410 Gone.

Planned Maintenance covers scheduled maintenance windows that could impact your services. Azure gives advance notice so you can prepare. If you're running GPU training jobs that take 48 hours, knowing about a maintenance window before you start the job matters.

Security Advisories cover vulnerabilities or security incidents affecting services you use. Critical patches, recommended actions, risk assessments for your deployment.

Most startups configure the first one and skip the rest.

"But won't I get spammed?"

The most common pushback when I suggest enabling all four types: "There are 250+ services in the filter list. If I select all of them, won't I drown in alerts?"

No. Service Health only fires notifications when Microsoft publishes an event affecting your subscription, for services you have deployed, in regions where you have resources. If you're running Container Apps, Key Vault, Cognitive Services, and Storage in East US, you get alerts for those. Everything else stays quiet.

I pulled the service list for a customer with 7 subscriptions recently. Across all of them, they had 23 resource types deployed. That's a very manageable alert volume, even with all four event types enabled.

The scope trap in the portal

This one trips people up. When you create an activity log alert rule, the portal shows a "Resource group" field that looks like it's required. That field is where the alert rule resource itself gets stored, not what it monitors. Service Health alerts are scoped at the subscription level.

You don't need a separate alert rule for each resource group. One rule per subscription covers everything in it. If you already have a Service Issues alert working, you set the scope correctly the first time. Edit that existing rule to enable all four event types, or create a new one and disable the old Service Issues-only rule (otherwise Service Issues fires twice).

Docs: Create activity log alert rule

You probably have more subscriptions than you think

Dev, staging, prod, shared services, maybe MSDN subs for engineers. Each subscription needs its own Service Health alert rule. Alerts on prod don't cover dev.

If you have 7 subscriptions and alerts on 1, that's 86% of your environment running without health notifications.

You can fix this at scale with Azure Policy. Microsoft provides a built-in policy called "Configure subscriptions to enable Service Health Monitoring Alert Rules." One policy assignment at the management group level, all current and future subscriptions get alerts automatically. One thing to note: for subscriptions that already exist at the time of assignment, you need to create a remediation task. Without it, the policy only evaluates newly non-compliant resources going forward.

Docs: Deploy Service Health alerts at scale using Azure Policy

Why this matters more for AI startups

If you're running Azure OpenAI in production, Health Advisories are where model retirement notices land. Azure periodically retires model versions and updates API versions. Without the advisory alert, your team finds out when something breaks in production.

Same story for GPU VMs. If you have long-running training jobs on ND or NC series, a maintenance window you didn't know about can kill a job that's been running for 3 days. Planned Maintenance alerts give you advance notice to checkpoint or reschedule. Azure typically provides about a 35-day self-service window for maintenance that requires a reboot. Within that window, you choose when to apply it. For more granular in-VM awareness, use Scheduled Events, which gives your workload about 15 minutes notice before a reboot actually happens. Long-running training jobs should checkpoint periodically regardless, but knowing the window exists lets you plan around it.

For security-conscious customers (and if you're handling inference at scale, you should be), Security Advisories flag vulnerabilities in services you're actually using. Not theoretical risks across all of Azure, just the ones relevant to your deployment.

Setup checklist

Open Azure Monitor, go to Alerts, create a new alert rule:

Select Service Health as the signal type:

Then configure:

Set scope to your subscription (not a resource group)
Signal type: Activity log, then Service Health
Enable all four event types: Service Issues, Health Advisories, Planned Maintenance, Security Advisories
Select all services (you'll only get alerts for ones deployed in your subscription/region)
Create an action group: email, Teams webhook, or both
Repeat for every subscription (or just disable the old rule if updating)

Or skip the manual work: assign the built-in Azure Policy at your management group level and let it propagate. Remember to create a remediation task for existing subscriptions.

Blog Post