Don’t rely on the global Azure status page—it’s a noisy grid that tells you nothing about your actual apps.
Microsoft Azure Service Health gives a real-time view of incidents, maintenance, advisories, and security notices that actually affect your subscriptions and regions.
This post shows you how to check live status, read the color-coded indicators, set up health alerts, and build a focused dashboard so your team hears about problems first and can act fast.

Check Azure Service Status Now

Azure Service Health gives you a real-time snapshot of what’s actually working and what’s broken across the services you care about. The global Azure status page just dumps every service and region into a giant grid. Service Health inside the Azure portal does something smarter: it shows you only the incidents, maintenance windows, and advisories that touch your subscriptions and regions.

You get four buckets of information. Service issues cover active outages and problems happening right now. Planned maintenance lists scheduled work that might knock things offline temporarily. Health advisories warn you about upcoming changes like service retirements or forced upgrades. Security advisories deal with identity threats, network vulnerabilities, and data protection guidance. Each entry tells you which service broke, which regions got hit, when it started, when Azure thinks it’ll be fixed, and what’s happening at the moment. If something’s on fire, the dashboard pulls up the specific resources in your subscription that might be affected so you can triage faster.

Here’s how to check what’s going on:

1. Log into the Azure portal at https://portal.azure.com
2. Go to All services > General > Service Health
3. Open the Service issues tab and scan for anything red or degraded that’s hitting your subscriptions
4. Check Planned maintenance and Health advisories to see what’s scheduled or what action items are coming your way

Can’t even get into the portal? That’s when you fall back to the global Azure status page to see if the whole platform’s having a bad day.

Understanding Azure Service Status Indicators

Azure Service Health uses colors to tell you how worried you should be. Green means everything’s fine. Yellow means pay attention, something’s not broken yet but you need to do something soon—maybe a service is retiring or there’s a config tweak you should make. Red means there’s an active incident dragging down availability or straight-up breaking functionality.

Each incident also gets a status label. “Investigating” means Azure’s still figuring out what went wrong. “Identified” means they found the root cause. “Mitigating” means they’re rolling out a fix. “Resolved” means it’s over and the incident’s closed. Security advisories get an extra layer—critical, important, moderate, or low—so you know which patches to drop everything for and which ones can wait until Tuesday.

When you’re scanning the dashboard, focus on:

• Red service issues where your actual resources show up in the “Impacted resources” section. Those need attention now.
• Yellow planned maintenance hitting in the next week that might cause brief downtime
• Advisory notices telling you to migrate to a new API or update something before a deadline

How to Access Azure Incident History

Service Health keeps a full archive of every incident, maintenance event, and advisory that’s touched your subscriptions. It’s useful for post-mortems, compliance audits, or just understanding if last month’s mystery slowdown matched a platform hiccup. Open the Service Health blade, click the Service issues tab, and use the date filter to pull up whatever historical window you want.

Closed incidents stick around with their full timeline and status updates. A few days after resolution, Azure usually posts a root-cause analysis that breaks down what failed, how they fixed it, and what engineering changes they’re making to stop it from happening again. You can download individual incident summaries and RCAs to attach to change-management docs or compliance reports. Reviewing history also helps you match up weird performance patterns with past outages or maintenance windows you didn’t notice at the time.

Setting Up Azure Service Health Alerts

Alerts let you stop checking the dashboard manually. You configure a rule, and Azure sends you a notification the second something affects your subscriptions—incidents, maintenance announcements, advisories, whatever you care about. You pick how you want to hear about it: email, SMS, push notification, or a webhook that dumps the alert into ServiceNow or PagerDuty.

Before alerts work, you need an Azure Monitor action group. That’s just a list of notification channels—an email address, a phone number for texts, a webhook URL. If you don’t have one yet, you can build it while setting up the alert.

Here’s the setup:

1. Open Service Health in the Azure portal and click Health alerts in the left menu
2. Click Add service health alert at the top
3. On the Scope tab, pick the subscription you want to watch (if you’ve got multiple subs, make a separate rule for each)
4. On the Condition tab, choose which event types to track (service issues, planned maintenance, health advisories, security advisories) and select services and regions—easiest move is to select everything so the rule automatically covers future resources too
5. On the Action tab, pick an existing action group or create a new one, configure your notification channels, then save the rule under the Details tab by choosing a subscription, resource group, and naming the thing

The rule shows up in your Health alerts list. Alerts fire immediately when Azure posts a matching event, so you’re not finding out about an outage three hours later or missing a maintenance deadline.

Interpreting Azure Advisories and Planned Maintenance

Planned maintenance means Azure’s about to do some work that might briefly take things offline. You usually get at least 7 days’ notice. The announcement includes which services and regions are affected, when the work starts and ends, and what they’re doing (like “host reboot for security patches”). Use that schedule to plan failovers, move batch jobs around, or warn stakeholders about a quick interruption.

Health advisories cover everything else that’s not an emergency but still matters. Service retirements announced a year out. Mandatory API upgrades. Misconfigs Azure found in your setup. Usage quota warnings. An advisory might tell you you’re about to hit your regional vCPU limit or that a legacy storage tier’s getting retired in six months. Each one includes what’s affected, what you should do, and when you need to do it by.

Security advisories focus on identity issues (credential policies, compromised accounts), network stuff (firewall changes, DDoS mitigations), data security (encryption settings, compliance updates), patches for platform components, and threat detection guidance. Treat these as tasks, not FYI messages. Review the steps, apply the patches or config changes, and double-check your environment meets the updated requirements before the deadline hits.

Creating a Personalized Azure Service Health Dashboard

A personalized dashboard surfaces only the incidents and metrics your team actually needs to see, filtered by the subscriptions, services, and regions you manage. The default Service Health view shows everything across every subscription you have Reader access to. A custom dashboard lets you pin tiles, apply filters, and share a clean status view with on-call engineers or whoever else needs it.

Here’s how to build one:

Filter by subscription and region: select only the subs and Azure regions where you actually run stuff, so the dashboard drops irrelevant global noise

Add status tiles: pin tiles for active service issues, upcoming planned maintenance, recent health advisories, and security advisories to one page

Configure resource-type filters: if you only manage VMs and SQL databases, filter the dashboard to show incidents and advisories for those services

Save and share the dashboard: name it, save it to your portal workspace, and use the Share feature to give read access to teammates or embed it in your monitoring tools

Dashboards update automatically when Azure posts new incidents or advisories, so your team’s always looking at current information. You can make multiple dashboards—one per environment (production, staging, test) or one per business unit—and flip between them in the portal. Pair a custom dashboard with Service Health alerts and you’ve got proactive notifications plus a central visual reference for what’s happening now and what’s coming next.

Final Words

Open the Azure Service Health dashboard now: it shows live status, incidents, and which regions are affected so you can act fast.

This guide walked you through reading status indicators, checking incident history, setting alerts, interpreting advisories and maintenance, and building a tailored dashboard.

Use microsoft azure service health to set alerts and customize views. A few minutes of setup saves hours during outages, so you’ll stay informed and ready.

FAQ

What is Azure Service Health and where do I access it?

Azure Service Health is Microsoft’s real-time dashboard that shows current service availability, active incidents, regional outages, and upcoming maintenance across all Azure services. You access it through the Azure portal by searching “Service Health” or visiting the dedicated Service Health blade in your subscription.

How do I check if Azure is currently down in my region?

To check if Azure is down in your region, open the Azure Service Health dashboard in the portal, select “Service Issues” from the left menu, and filter by your geographic region and the specific services you use. The dashboard displays color-coded status indicators showing healthy services (green), advisories (yellow), and active outages (red) with regional impact details.

What do the different Azure status indicator colors mean?

Azure status indicators use green to show healthy services running normally, yellow to signal advisories or performance concerns that don’t block core functionality, and red to indicate active outages or incidents causing service disruption. These color codes appear on the Service Health dashboard and help you quickly assess service conditions.

How far back does Azure Service Health store incident history?

Azure Service Health maintains a searchable log of past incidents including root-cause summaries, affected services, timestamps, and resolution details. You can access this historical data through the “Health History” section in the Service Health blade, which helps with troubleshooting recurring issues and meeting audit or compliance requirements.

Can I get automatic alerts when Azure services go down?

Yes, you can configure Azure Service Health alerts to notify you via email, SMS, or webhook when incidents or maintenance events affect your selected services or regions. Set up alert rules in the Azure portal by choosing the resource types you want to monitor, selecting notification channels, and defining the geographic scope.

What’s the difference between Azure advisories and planned maintenance notices?

Azure advisories provide warnings about optimization opportunities, performance concerns, or configuration recommendations that don’t require immediate action, while planned maintenance notices detail upcoming scheduled changes that may temporarily impact service availability. Advisories help you improve your setup proactively, whereas maintenance notices let you prepare for brief service interruptions with specific time windows.

How do I create a custom dashboard to monitor specific Azure services?

To create a custom Azure Service Health dashboard, open the Azure portal, navigate to Dashboard, add Service Health tiles for the services you want to track, filter by your target regions, and configure alert integrations. This personalized view lets you monitor only the services and regions relevant to your workloads without scanning the entire global status.

How do I know if an Azure outage will affect my application?

Check the Azure Service Health “Service Issues” section and filter by the specific services your application depends on and the regions where you’ve deployed resources. The incident details show which service components are impacted, affected regions, and the scope of disruption, helping you determine if your workload is at risk.