Azure Service Health vs Resource Health: Explained

Azure Service Health provides a global view of the health of Azure services across all regions, including planned maintenance and outages. In contrast, Azure Resource Health provides a granular, resource-specific view, telling you if a specific VM or database is down and why, allowing for targeted troubleshooting.

What exactly is Azure Service Health?

Think of Azure Service Health as your "big picture" dashboard. It is the primary place where Microsoft communicates the status of the Azure platform as a whole. Instead of guessing why a service is lagging, you check Service Health to see if there are any global or regional outages. It categorizes information into three main areas: Service issues (current outages), Planned maintenance (upcoming updates), and Health advisories (recommendations to improve your setup).

For those of you studying for the AZ-900, remember that Service Health is about the platform, not your specific configuration. If you see a regional outage listed here, it means the problem is on Microsoft's end. There is no amount of tweaking your settings that will fix a regional backbone failure; your only move is to monitor the status and wait for the platform to recover or failover to another region.

How does Azure Resource Health differ?

While Service Health looks at the forest, Azure Resource Health looks at a single tree. This tool provides a granular, resource-specific view of your environment. If your specific Virtual Machine (VM) or SQL Database suddenly stops responding, but the rest of the Azure region is fine, Resource Health is where you go. It gives you a binary status: is the resource "Available" or "Unavailable"?

When a resource is marked as unavailable, Resource Health doesn't just tell you it's broken; it provides a specific reason. For example, it might indicate a hardware failure on the underlying physical host. This is a game-changer for troubleshooting because it eliminates the guesswork. You no longer have to wonder if your application code crashed or if the underlying Azure hardware failed—the tool tells you exactly where the fault lies.

Which tool should you use in a real-world outage?

Let's put this into a practical scenario. Imagine you're the admin for a retail site and users report that the checkout page is down. Your first instinct should be to check Resource Health for the specific App Service or VM hosting that page. If Resource Health shows the resource is "Available," the problem is likely within your application code or a networking misconfiguration.

However, if Resource Health shows the resource is "Unavailable" due to a platform issue, your next step is to check Azure Service Health. If Service Health shows a widespread outage in your region (e.g., East US), you know the issue is systemic. This distinction is critical for operational efficiency. Checking the wrong tool first can lead you down a rabbit hole of debugging code when the actual problem is a severed fiber optic cable in a Microsoft data center.

How do you configure personalized health alerts?

You shouldn't be manually refreshing dashboards every morning. To be a pro admin, you need to configure personalized Service Health alerts. This allows you to receive notifications via email, SMS, or push notifications the moment an issue affects your specific subscription. You can filter these alerts by region and by service type, ensuring you aren't spammed with notifications for services you don't even use.

Setting up these alerts is particularly important for planned maintenance. Microsoft will often notify you weeks in advance that a specific host will be updated. By receiving these alerts, you can proactively migrate your workloads or schedule downtime during off-peak hours. In a production environment, missing a maintenance notification can lead to unexpected downtime that could have been easily avoided with a simple alert configuration.

What are the remediation steps for resource-level failures?

When Resource Health flags a failure, your remediation path depends on the root cause provided. If the failure is attributed to the underlying platform (like a host crash), the fastest fix is often a "Redeploy" action. This tells Azure to move your VM to a different, healthy physical host in the data center, effectively bypassing the hardware failure.

If the failure is not platform-related, you'll need to dive into the Activity Log to see who changed what and when. Always document these incidents. Knowing whether the fault lay with the provider or the user is key to maintaining your Service Level Agreements (SLAs). If you can prove the outage was a platform failure, you may be eligible for service credits depending on your support tier. This level of detail is what separates a junior admin from a seasoned professional.

Why is this distinction critical for the AZ-900 exam?

Microsoft loves to test your ability to choose the right tool for the right scenario. You will almost certainly encounter a question asking whether to use Service Health or Resource Health to diagnose a problem. The key is to look for keywords: "regional," "global," or "platform" point toward Service Health, while "specific resource," "VM status," or "individual instance" point toward Resource Health.

If you're finding these distinctions tricky, we've got you covered. At Cert Sensei, we offer 1,000 expert-curated Microsoft Azure Fundamentals (AZ-900) practice questions. We don't just give you the answer; we provide detailed expert reasoning for every single question and domain-level analytics. This allows you to see exactly where you're struggling—whether it's cloud concepts or Azure management tools—so you can study smarter and pass on your first attempt.

❓ Frequently Asked Questions