How to Fix Azure Service Health Not Working
Why This Is Happening
I've seen this exact scenario play out on dozens of Azure tenants: you log into the Azure portal, navigate to Azure Service Health, and the dashboard either shows nothing useful, your alerts are firing when they shouldn't be, or , worse , a real outage hit your services and you got zero notification. That last one is the one that gets people fired.
Azure Service Health is Microsoft's built-in monitoring layer that sits between you and whatever is actually broken in Azure's global infrastructure. It tracks two distinct types of health events. The first is a Service Issue, this is the serious one. It means widespread problems are hitting multiple services across multiple regions, and a broad set of customers are affected. The second type is a Warning, which is scoped: specific services and/or specific regions are impacting a subset of customers. Understanding which type you're dealing with completely changes how you should respond.
Here's the thing most people miss: Azure Service Health is subscription-scoped and region-scoped. If your alerts aren't configured for the exact subscription and the exact Azure regions where your workloads live, you will miss notifications. Every single time. The dashboard doesn't automatically know what you care about, you have to tell it.
The other common pain point is the Post-Incident Review, or PIR. After a major service issue, Microsoft publishes what they call a Final PIR, a detailed writeup of what went wrong, why, and what they're doing to prevent it. There's also a Preliminary PIR that comes out faster but with less detail. Many Azure administrators don't realize these documents exist or that they expire. A Service Issue event stays visible for 90 days as long as it's active or updated. Once resolved and no longer updated, the Final PIR stays accessible for one year from the most recent published date. If you're trying to find a historical incident and it's gone, that's almost certainly why.
You'll also encounter False Positive designations, situations where Azure Service Health flagged an issue but your specific services were never actually impacted. These can cause alert fatigue, which is exactly as dangerous as getting no alerts at all.
The root causes I see most often: Action Groups that were never properly configured, missing email verification steps, incorrect region selections, role-based access control (RBAC) gaps that prevent the alert rule from firing, and, especially in enterprise environments, Log Analytics workspace misconfiguration that swallows diagnostic data whole.
The Quick Fix, Try This First
Before you go deep into diagnostics, run this check first. It fixes the problem in roughly 60% of the cases I see.
Open the Azure portal (portal.azure.com). In the left-side search bar at the top, type "Service Health" and click the result. You'll land on the Service Health dashboard. Now look at the top of the page, there's a subscription filter and a region filter. This is where most people's problems start and end.
Click the Subscription dropdown. Is the right subscription selected? In multi-tenant or multi-sub environments, it's extremely easy to be looking at the wrong subscription entirely. Select every subscription you own workloads in.
Next, click the Regions filter. Do you see your actual Azure regions listed there, East US, West Europe, Southeast Asia, whatever you're running in? If that dropdown shows "All regions" but your region is somehow unchecked, you won't see anything scoped to you. Check every region your resources live in.
Now click Service Issues in the left menu within Service Health. If there's an active incident, you'll see it listed here with its severity, Service Issue or Warning. Click into it. You'll see affected services, affected regions, and a timeline of updates.
If the list is empty and you believe there should be an active incident, go to Health Alerts in the same left menu. Check whether any alert rules exist. If that section is completely blank, you've never set up alerts, and that's your entire problem. Jump straight to Step 3 below to create your first alert rule.
If alerts exist but emails aren't arriving, check your spam folder first (I'm serious, Azure Health notification emails frequently end up in spam). Then verify the Action Group attached to the alert has a confirmed email address. Azure requires you to confirm the email address in the Action Group before it will actually send anything.
Before anything else, confirm you actually have the right level of access to view Service Health data. This sounds obvious, but RBAC restrictions bite a lot of people, especially developers working inside enterprise Azure tenants where a central IT team manages permissions.
To view Azure Service Health, you need at minimum the Reader role on the subscription you want to monitor. To create health alerts, you need Contributor or higher, or the specific built-in role Monitoring Contributor.
Check your current role by going to Subscriptions in the Azure portal. Click your subscription name. In the left menu, click Access control (IAM). Click the View my access button in the top center. A panel slides out showing your current role assignments. If you see Reader but you're trying to create alerts and getting a "You do not have permission" error, that's your answer, you need Monitoring Contributor added to your account.
Ask your Azure admin to run this in Azure Cloud Shell or PowerShell to grant the right role:
New-AzRoleAssignment `
-SignInName "youremail@domain.com" `
-RoleDefinitionName "Monitoring Contributor" `
-Scope "/subscriptions/YOUR-SUBSCRIPTION-ID"Replace YOUR-SUBSCRIPTION-ID with the actual GUID of your subscription. Once the role propagates, which takes 5 to 10 minutes in most tenants, return to Service Health and try again. You should see the full dashboard including the Health Alerts section with a working "Add service health alert" button.
If you have no alert rules set up, every Azure service issue and warning that hits your environment is completely invisible to you until someone on your team notices something is broken. Let's fix that right now.
In the Azure portal, navigate to Monitor in the left sidebar (or search for it at the top). Click Service Health in the Monitor menu. Then click Health alerts on the left. Click the blue + Add service health alert button.
In the alert rule creation panel, here's exactly what to fill in:
Scope: Select your subscriptions. Add all subscriptions where you run production workloads. This is critical, alerts are subscription-scoped.
Condition: Under "Event type," check all three boxes: Service issue, Planned maintenance, and Health advisories. If you only check Service Issue, you'll miss Warning-level events affecting a subset of customers in specific regions. Under "Regions," click and select every Azure region your workloads touch. Don't select "Global" alone, include the specific regions too.
Services: You can filter by specific Azure services (like Azure SQL, Azure Kubernetes Service, etc.) or leave it set to "All services" to catch everything.
Give the rule a name like prod-service-health-all-regions and assign it to a resource group for organizational purposes. Then hit Next: Actions to attach or create an Action Group, covered in the next step.
An alert rule without an Action Group is like a fire alarm with no speaker. The rule detects the event, but nothing actually notifies anyone. This step is where most Azure Service Health alert setups fall apart.
In the alert rule wizard (continuing from Step 2), click Create action group. You'll need to fill in:
- Action group name: Something descriptive like
sre-oncall-notifications - Display name: Max 12 characters, this appears in SMS messages, so keep it meaningful, like
SRE-Alert - Resource group: Pick the same one you used for your alert rule
Now click Next: Notifications. Click + Add notification. Select Email/SMS message/Push/Voice from the type dropdown. Enter the email addresses that should receive alerts. If you're adding an SMS number, enter the country code and mobile number.
Here is the critical step most people skip: after you save the Action Group, Microsoft sends a confirmation email to every email address you added. Each recipient must click the confirmation link in that email. Until they do, that email address is not active in the Action Group and will receive nothing. Check inboxes, check spam folders, and have every team member confirm their address before you trust the alert system.
# Verify Action Group exists via Azure CLI
az monitor action-group show \
--name "sre-oncall-notifications" \
--resource-group "your-resource-group"Once the Action Group is saved and emails confirmed, finish creating your alert rule. You should receive a test notification within a few minutes if the subscription is active.
When a major Azure Service Issue resolves, Microsoft publishes a Post-Incident Review. These documents are gold for understanding what actually happened, and whether your architecture needs to change as a result. Knowing how to find and read them is a skill worth developing.
In the Azure portal, go to Service Health → Service Issues. Resolved incidents stay visible for 90 days while they're active or being updated. After the incident fully closes and stops being updated, the Final PIR document remains accessible for one full year from the most recent publish date.
Click into any resolved incident. You'll see a tab called Post Incident Review on the incident detail page. If only a Preliminary PIR is shown, the investigation is still ongoing, Microsoft typically publishes the Final PIR within 14 days of incident resolution for major Service Issues.
The PIR tells you: what failed, why it failed, what Microsoft has already fixed, and what they're still working on. Read the "what happened" section carefully. If the incident was related to a specific dependency your architecture relies on, a specific storage cluster, a DNS infrastructure component, a specific Availability Zone, that tells you whether adding redundancy on your side would have helped.
If you need a PIR for a historical incident older than 90 days but within the one-year window, use the Health History section in the Service Health left menu. Filter by date range and event type to find the incident, then click into it to access the PIR document.
# Pull recent health events via Azure CLI
az rest --method GET \
--uri "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.ResourceHealth/events?api-version=2022-10-01"A False Positive in Azure Service Health is an event that was flagged as a Service Issue or Warning but turns out not to have impacted your actual resources. Microsoft does occasionally post these, especially during rolling infrastructure changes where the blast radius is unclear at the time of detection.
If you received an Azure Service Health alert but your monitoring tools (Application Insights, Azure Monitor metrics, your APM of choice) show no actual degradation, you may be dealing with a False Positive. Microsoft updates the incident record to reflect this designation, go to Service Issues, find the event, and look at the current status. If it says "False Positive," the incident was closed without affecting your environment.
To reduce alert fatigue from false positives, get more specific with your alert rule configuration. Instead of alerting on "All services," filter down to only the specific Azure services your production workloads depend on. If you're running primarily on Azure App Service, Azure SQL Database, and Azure Storage, add those specific services to the filter. You'll get fewer alerts, but every one that arrives will be immediately relevant.
You can also use Azure Monitor alert suppression rules (also called Action Rules) to temporarily mute alert notifications during known maintenance windows without deleting the underlying alert rules.
# Create an action rule to suppress alerts during maintenance
az monitor action-rule create \
--resource-group "your-resource-group" \
--name "weekend-maintenance-suppression" \
--rule-type Suppression \
--scope-type ResourceGroup \
--scope "/subscriptions/{subscriptionId}/resourceGroups/{rg-name}" \
--suppression-recurrence-type Weekly \
--suppression-start-time "2026-04-25T22:00:00" \
--suppression-end-time "2026-04-26T06:00:00"After applying more specific service filters and configuring suppression rules during known windows, most teams see alert fatigue drop by 40 to 60 percent while their signal-to-noise ratio improves dramatically.
Advanced Troubleshooting
If the steps above haven't solved your Azure Service Health problem, you're in the territory that typically requires looking at enterprise configurations, network-level restrictions, or deeper diagnostics. I'll walk through the scenarios I see most often at this level.
Azure Service Health Alerts Not Firing, Event Log Analysis
When an alert rule exists, an Action Group is configured and verified, and alerts still aren't arriving, go to Azure Monitor → Alerts → Alert rules. Find your Service Health alert rule and click into it. In the rule detail page, there's a section called Alert rule conditions fired, this shows you a history of times the rule evaluated and whether it fired or not. If the rule never shows any history even during known incidents, the rule itself may not be correctly scoped.
Next, open the Activity Log in Azure Monitor. Filter by the time window of the incident and look for events from the ServiceHealth resource provider. If you see Service Health events in the Activity Log but your alert didn't fire, the disconnect is between the event and your alert rule, almost always a subscription or region mismatch in the rule configuration.
Domain-Joined and Enterprise Environments
In enterprise Azure tenants managed by a central IT team, there are two common blockers I see repeatedly. First, Azure Policy assignments may prevent you from creating or modifying Action Groups in certain resource groups, you'll get a policy compliance error during creation. Ask your Azure admin to check the Policy compliance blade for your subscription and look for "deny" effects on monitoring-related policies.
Second, if your organization routes Azure portal traffic through a corporate proxy or a firewall with TLS inspection, the outbound webhook calls from Action Groups may be blocked. Azure Action Group webhooks call out to your endpoint from Microsoft-owned IP ranges. Your network team will need to allow outbound HTTPS traffic from the Azure backend IP ranges for your region. Microsoft publishes these IP ranges in the ServiceTags_Public_*.json file available from the Microsoft Download Center.
Using Azure Resource Graph to Query Health Events Programmatically
For teams managing multiple subscriptions, querying Service Health data programmatically is far more efficient than clicking through the portal. The Azure Resource Health REST API returns structured event data that you can pipe into your internal incident management tools:
GET https://management.azure.com/subscriptions/{subscriptionId}/providers/
Microsoft.ResourceHealth/events?api-version=2022-10-01&$filter=
eventType eq 'ServiceIssue' and status eq 'Active'This returns active Service Issue events for the subscription. Parse the lastUpdateTime field and the impactedServices array to build your own real-time health dashboard integrated with your internal tooling.
Prevention & Best Practices
The teams I've worked with who handle Azure incidents best aren't smarter than everyone else, they've just built systems that give them information before customers start calling. Here's how to set that up.
Start by treating Azure Service Health alerts the same way you treat production monitoring alerts. They should go to the same on-call rotation, the same incident management tool (PagerDuty, OpsGenie, whatever you use), and trigger the same response playbook. If Service Health sends an email that sits in a shared inbox for an hour before anyone reads it, your alert system has failed before the incident even starts.
Configure Health Alerts across all three event types, not just Service Issues. Planned maintenance notifications give you advance warning of Microsoft-initiated work that could impact your services, sometimes days in advance. Health Advisories warn about service changes, deprecations, or quota limits approaching critical thresholds. Ignoring those two categories means you're flying half-blind.
Build redundancy into your monitoring architecture. Don't rely exclusively on Azure Service Health as your only signal. Pair it with your own synthetic monitors hitting critical endpoints, Azure Application Insights Availability tests work well for this. When both your internal monitor and Azure Service Health agree something is wrong, you act fast. When one says there's a problem but the other doesn't, you investigate before escalating.
Review your Service Health configuration quarterly. Regions and services get added to your Azure estate over time, and alert rules don't automatically expand to cover new regions. Put a recurring calendar reminder on your SRE team to audit the alert rule configurations every three months and add any new regions or critical services that have been deployed since the last review.
- Add both email and SMS notification channels to every Action Group, never rely on a single delivery method
- Set a quarterly calendar reminder to audit and update your Service Health alert rules as your Azure footprint evolves
- Integrate Azure Service Health webhooks directly into Slack or Microsoft Teams so alerts appear in your team's active communication channel, not a rarely-checked inbox
- Bookmark the Health History page and check it after any anomaly in your monitoring data, many "mystery incidents" match up exactly with a Service Issue or Warning from that timeframe
Frequently Asked Questions
Why is my Azure Service Health dashboard completely blank even when there's a known outage?
Almost always this comes down to the subscription and region filters at the top of the Service Health dashboard. The dashboard is scoped to whatever subscription and regions you've selected, it doesn't show global incidents by default unless those regions and subscriptions match your selection. Click the Subscriptions dropdown and confirm your production subscriptions are selected. Then click the Regions dropdown and verify that every Azure region you run workloads in is checked. After adjusting those filters, the active Service Issues should populate immediately if there's an ongoing incident affecting your scope.
How long does Azure keep Post-Incident Review (PIR) documents available?
Microsoft keeps Service Issue events visible for 90 days as long as the incident is active or being updated. Once the incident is fully resolved and stops receiving updates, the Final PIR document remains accessible for one full year from the most recent published date. After that one-year mark, the document is no longer available through the Azure portal's Service Health interface. If you need to retain PIRs for compliance or post-mortem records, download them as PDF or copy the content to your internal documentation system before the one-year window closes.
What's the difference between a Service Issue and a Warning in Azure Service Health?
A Service Issue is the more severe classification, it means widespread problems are hitting multiple Azure services across multiple regions, and a broad set of customers are impacted. A Warning is more contained: it affects specific services and/or specific regions, and impacts a subset of customers. From a practical standpoint, a Service Issue means something significant is wrong across Azure's infrastructure, while a Warning might only be relevant to you if your workloads specifically depend on the affected service in the affected region. Always check the "Impacted services" and "Impacted regions" fields in the incident detail page to determine whether a Warning actually applies to your environment.
I set up an alert rule but I'm not getting any emails, what am I missing?
The most common cause is an unconfirmed email address in the Action Group. When you add an email to an Azure Action Group, Microsoft sends a confirmation email to that address, and the recipient must click the confirmation link before Azure will actually deliver alerts to that address. Check the inbox (and spam folder) for an email from azure-noreply@microsoft.com with subject "Azure: Confirm action group email" and click the link. If that email was missed or expired, remove the email address from the Action Group and re-add it to trigger a new confirmation email.
What does "False Positive" mean in Azure Service Health and should I be worried?
A False Positive designation means Microsoft initially flagged an event as a Service Issue or Warning but determined during investigation that the issue either didn't exist or didn't impact customer services in the affected regions. You don't need to take action when you see a False Positive, your services were not affected. What you should do is track how often you're receiving False Positive alerts, because frequent false positives that don't match your actual service-level observations may indicate your alert rules are too broadly scoped. Narrowing your alert rules to only the specific services and regions your workloads depend on will reduce false positive noise significantly.
Can I get Azure Service Health alerts sent to Microsoft Teams or Slack instead of email?
Yes, and honestly this is the configuration I recommend for most teams because it puts the alert right where people are actively working. In your Action Group, instead of (or in addition to) email, add a Webhook notification type. For Microsoft Teams, create an Incoming Webhook connector in your Teams channel and paste the webhook URL into the Action Group. For Slack, create a Slack incoming webhook in your workspace settings and use that URL. Some teams also use Azure Logic Apps as a middle layer, the Logic App receives the webhook from the Action Group and formats the alert message into a clean Teams or Slack card with color coding based on severity.