Azure Service Health vs Resource Health

Azure gives you three distinct ways to answer “is Azure working right now,” each scoped differently. The public Azure Status page shows global, unauthenticated health for every service and region, the same view for everyone. Azure Service Health is a personalized, sign-in-required dashboard scoped to the specific services and regions your subscription actually uses. Azure Resource Health narrows further still, reporting the health of one individual resource instance and whether any issue was caused by the Azure platform or by your own action.

The public status page: global and unfiltered

The Azure Status page, at status.azure.com, shows the current health of every Azure service across every region, and anyone can view it without signing in or specifying a subscription. That’s exactly its strength and its limitation: it’s useful for a quick “is Azure having a bad day anywhere” check, but it tells you nothing about whether the specific services and regions your workloads run in are affected. If you operate entirely in one region and a different region has a problem, the status page shows red anyway, because it isn’t personalized to you.

Service Health: scoped to what you actually use

Azure Service Health, found in the Azure portal, filters that same underlying incident data down to the subscriptions, resource types, and regions you select. Instead of seeing every incident happening anywhere in Azure, you see only what’s relevant to your own footprint, which is what makes it usable as an operational tool rather than background noise. Service Health organizes what it shows into four components:

Component	What it covers
Service issues	Active, in-progress incidents currently affecting the services/regions you use
Planned maintenance	Scheduled infrastructure changes Microsoft has announced in advance
Health advisories	Notices requiring awareness or action, such as feature deprecations
Security advisories	Security-relevant notifications affecting the services you use

A common trap is confusing this list with Azure Advisor’s five recommendation categories (Cost, Security, Reliability, Operational Excellence, Performance) — they sound similar but come from two entirely different tools with different purposes. Service Health reports platform status; it doesn’t recommend configuration changes.

Resource Health: one resource, current and historical

Where Service Health looks at services and regions broadly, Azure Resource Health drills into a single resource instance — one specific virtual machine, for example — and reports its current and recent historical health status. Critically, it labels why an event happened: platform-initiated means Azure infrastructure or Microsoft caused the interruption, such as a host reboot for scheduled maintenance or an underlying hardware fault, while non-platform (or user-initiated) means an action the customer took, such as stopping or resizing the VM, caused it. This distinction is exactly what you need when one resource goes unresponsive but the public status page shows everything healthy and no other customers are reporting problems — Resource Health for that specific resource is the tool built to tell you whether the fault sits with Azure or with something you did. That platform-versus-user distinction also matters for high availability and SLAs, since Microsoft’s uptime commitments only account for platform-caused outages, not interruptions you triggered yourself.

Telling the three apart by scope

The fastest way to keep these straight is to think in terms of scope, narrowing from broadest to narrowest:

• Azure Status page — global, every service, every region, no sign-in required, identical for every visitor.
• Service Health — personalized to your subscription’s services and regions, requires sign-in, lives in the portal under the Service Health blade.
• Resource Health — a single resource instance, showing current status plus a platform-vs-user-caused explanation for any event.

None of the three overlaps with Azure Advisor, which is a separate, configuration-recommendation engine rather than an incident or status feed — Service Health and Resource Health tell you about things happening to your resources, while Advisor tells you how to configure them better.

Getting notified automatically

Checking a dashboard manually doesn’t scale, so both Service Health and Resource Health support alert rules. A Service Health alert is an activity log alert tied to an action group; when a matching event — a service issue, planned maintenance notice, or advisory — is posted for the resources and regions you’ve selected, the action group can send email, SMS, a push notification, or a webhook to an external system like a ticketing tool. Because the alert is scoped to specific resources and event types, teams avoid being flooded with notices about services or regions they don’t actually use. This is the standard way organizations move from someone manually refreshing a status page to genuinely proactive notification.

How the AZ-900 exam tests this

• A scenario needs to distinguish “checking one specific VM’s status” from “checking a broad regional outage” — the answer for the single resource is Resource Health, not Service Health or the status page.
• A question describes wanting notifications scoped only to services and regions actually used, filtering out irrelevant global noise — that’s Service Health’s personalization, contrasted against the unfiltered public status page.
• A scenario describes a VM event and asks whether it was “platform-initiated” or “non-platform” — expect wording about host maintenance or hardware faults (platform) versus a customer stopping or resizing a VM (user/non-platform).
• A question lists Service Health’s four components and asks you to pick genuine ones (service issues, planned maintenance, health advisories, security advisories) versus decoys borrowed from Advisor’s categories (cost, performance, reliability) or unrelated concepts.
• A scenario wants automated email or webhook notification instead of manual checking — the answer is a Service Health alert rule with an action group attached, not a manual refresh routine or an Advisor Score check.

Quick reference

• Azure Status page: global, unauthenticated, identical view for everyone — no personalization.
• Azure Service Health: personalized to your subscription’s actual services and regions; requires sign-in; lives in the portal.
• Service Health’s four components: service issues, planned maintenance, health advisories, security advisories.
• Azure Resource Health: health of one specific resource instance, current and recent historical.
• Resource Health labels causes as platform-initiated (Azure’s fault) or non-platform/user-initiated (your action).
• Configure a Service Health alert with an action group for automatic email, SMS, or webhook notification instead of manual checking.
• Service Health and Resource Health report status; they don’t recommend configuration changes — that’s Azure Advisor’s job.

For deeper telemetry on your own applications rather than the Azure platform itself, see Azure Monitor logs, metrics, and alerts — and if you want to see how these scope distinctions show up as exam questions, work through AZ-900 practice questions that walk through realistic outage-diagnosis scenarios.