Resource Health and Azure Service Health

Azure provides two distinct but complementary health monitoring services: Resource Health and Azure Service Health. Both are part of the Azure Monitor suite, but they serve different purposes.

Resource Health gives you a personalized dashboard of the health of your individual Azure resources (e.g., a specific VM, storage account, or SQL database). It detects whether a resource is available, degraded, or unavailable, and provides root cause analysis (RCA) when issues occur. It runs checks every 1-2 minutes and reports status in near real-time.

Azure Service Health is a broader service that tracks the health of Azure services across regions. It provides information about: - Service issues: Ongoing problems affecting Azure services (e.g., a regional outage). - Planned maintenance: Upcoming maintenance that may impact your resources. - Health advisories: Changes that require your attention, such as service retirements or feature deprecations.

Both services are built on the same underlying health monitoring infrastructure, but Resource Health operates at the resource level, while Service Health operates at the service and subscription level.

Resource Health uses a series of health checks performed by the Azure Resource Health service. These checks are executed from multiple Azure datacenter locations to avoid single points of failure. The checks include: - Platform health checks: Verify that the underlying Azure platform (e.g., host server, network, storage) is working correctly. - VM health checks: For virtual machines, Resource Health checks whether the VM is running, responding to guest OS-level probes, and has network connectivity. - Application health checks: For services like App Service, it checks if the application pool is running and responding.

Each check returns one of three states: - Available: The resource is healthy and functioning normally. - Degraded: The resource is functioning but with reduced performance or availability. For example, a VM might be running but with high latency to its disk. - Unavailable: The resource is not functioning. For example, a VM has stopped.

Resource Health also provides historical health data for up to 30 days, allowing you to review past incidents.

Azure Service Health aggregates health information from all Azure regions and services. It uses a global monitoring system that collects telemetry from Azure datacenters worldwide. When a problem is detected (e.g., a regional power outage), the system creates a service health event that can be viewed in the Azure portal or queried via the Azure Resource Manager API.

Service Health events are categorized as: - Service Issue: An ongoing problem affecting one or more Azure services in a region. - Planned Maintenance: Scheduled updates that may impact your resources. - Health Advisory: Important changes or recommendations (e.g., TLS 1.2 deprecation). - Security Advisory: Security-related announcements (e.g., a vulnerability disclosure).

You can configure Service Health alerts to notify you via email, SMS, webhook, or Azure Monitor action groups when a service health event occurs that matches your criteria (e.g., a service issue affecting your subscription's region).

View Resource Health for a VM: 1. In the Azure portal, navigate to the VM. 2. Under 'Help', click 'Resource health'. 3. You'll see the current health state and any past events.

View Azure Service Health: 1. In the Azure portal, search for 'Service Health'. 2. The dashboard shows active service issues, planned maintenance, and health advisories.

Create a Service Health Alert using Azure CLI:

az monitor activity-log alert create \
  --resource-group MyResourceGroup \
  --name ServiceHealthAlert \
  --condition category=ServiceHealth \
  --action-groups /subscriptions/.../actionGroupName

Query Resource Health via Azure Resource Graph:

resources
| where type =~ 'microsoft.resourcehealth/availabilitystatuses'
| where properties.availabilityState == 'Unavailable'

In a typical enterprise scenario, a company runs hundreds of VMs across multiple regions. The cloud operations team uses Resource Health to monitor individual VMs. For example, if a VM shows 'Degraded' due to high disk latency, the team can investigate whether the disk is throttled or if there's a regional storage issue. They also set up Service Health alerts for 'Service Issues' in their primary region. When an Azure regional outage occurs, they receive an alert within minutes, allowing them to failover to a secondary region using Azure Site Recovery.

Another scenario involves a SaaS provider that uses Azure SQL Database. They rely on Resource Health to detect when a database becomes unavailable. They have an automation runbook that triggers when a database enters 'Unavailable' state: the runbook attempts to restart the database or failover to a geo-replica. They also subscribe to Service Health advisories to get early warnings about SQL database version retirements.

A common problem arises when administrators confuse Resource Health with guest OS monitoring. For example, a VM might be 'Available' per Resource Health, but the application inside the VM is down due to a misconfigured firewall. Resource Health does not check guest-level processes. To get application-level health, you need to use Azure Monitor for VMs or custom health probes.

Performance considerations: Resource Health checks run every 1-2 minutes, so there is minimal overhead. However, if you have thousands of resources, the Azure Resource Graph query might take a few seconds. For real-time alerting, use Resource Health alerts (preview) that trigger on state changes.

When misconfigured, teams might miss critical alerts. For instance, if Service Health alerts are not configured for all regions, a regional outage in a secondary region might go unnoticed until users complain. Also, if action groups are misconfigured (e.g., wrong email address), notifications are lost.