Azure Service Status: How to Check for an Outage

Azure service status is published in two places, and they answer different questions. The public status page reports incidents wide enough to affect many customers; Service Health, inside the Azure portal, reports what affects your own subscriptions and regions.

If the public page looks clean but your resources are failing, that is not a contradiction. Check Service Health before concluding that the problem is in your own code.

Is Azure down right now, or is it just my subscription?

Start with the narrowest view and widen out. A single failing resource is far more common than a regional outage.

1. Check Resource Health for the specific resource that is failing. It reports whether that one instance is healthy, degraded, or unavailable, and whether the cause is platform-side or your own configuration.
2. Check Service Health for your subscription, filtered to the region and service in question.
3. Only then check the public status page for a broad incident.

Going the other way round wastes time, because the public page is the last place a narrow incident appears, if it appears at all.

What is the difference between the status page and Service Health?

The public status page is a general announcement channel. It shows large incidents by service and region and is readable without signing in, which makes it the only option when you cannot reach the portal.

Service Health is personalised. It shows incidents that Microsoft has matched to your subscriptions, planned maintenance that will touch your resources, and health advisories about changes coming to services you use. It requires a sign-in, and it is where most teams should be looking.

Resource Health is narrower still: the state of one resource, with a history of when it changed.

Which region are my resources in?

Azure incidents are almost always scoped to a region, so an outage announcement means nothing until you know where your resources live. A subscription commonly spans several regions without anyone intending it.

Check the region on the resource's overview page in the portal. If you run resources in more than one region, note them all: a service can be healthy in one and degraded in another at the same moment.

How do I tell an Azure outage from a fault in my own app?

• Timing. If failures started at the same minute as your last deployment, look at the deployment first.
• Blast radius. One application failing while other resources in the same region are fine points at your app. Everything in a region failing at once points at the platform.
• Error type. Authentication failures, quota and throttling limits, and expired certificates or secrets are configuration problems, not outages, even though they arrive as sudden total failures.
• Another region. If the same workload runs elsewhere and is healthy, that is a strong regional signal.
• Read-only checks. If the portal itself is slow or errors, that is a platform symptom worth noting in your report.

What do the status labels mean?

• Good, or available. No incident is being tracked for that service and region.
• Degraded, or service degradation. The service responds but with errors, timeouts or reduced capacity.
• Service interruption. The service is failing for affected customers in that region.
• Planned maintenance. Announced in advance and expected to cause a defined disruption window.
• Health advisory. Not an outage: a change, deprecation or action you need to take before a date.

Incidents are updated as they are investigated, and the first message is usually vague on purpose. A detailed cause arrives afterwards in a post-incident review.

How do I get told about Azure incidents automatically?

Checking a page during an incident is the wrong time to find out about it. Service Health lets you create alert rules so incidents that match your subscriptions, regions and services notify you directly.

1. Open Service Health in the portal and create a health alert rule.
2. Scope it to the subscriptions, services and regions you actually run in, not to everything.
3. Choose which event types matter: service issues, planned maintenance, health advisories.
4. Attach an action group so the alert reaches email, a chat channel, or your on-call system.
5. Test the rule once so you know what the message looks like before a real incident.

What can I do while an Azure service is degraded?

During a confirmed platform incident, restarting resources repeatedly usually makes recovery slower and can leave you in a worse state than the outage itself. Prefer these:

• Fail over to a secondary region if you have one configured and tested.
• Turn off non-essential background jobs so they are not retrying against a failing service.
• Put a status message in front of your own users. They are asking you, not Microsoft.
• Hold off on deployments until the incident closes, so you are not debugging two problems at once.

How do I report an Azure problem to Microsoft?

If Resource Health and Service Health both look clean but your resources are clearly failing, open a support request in the portal rather than waiting for a public announcement. Sign in at the company’s official website and use the help and support section.

Have ready: the subscription ID, the resource ID or name, the region, the exact error codes and correlation IDs from your logs, and the time window in UTC. Correlation IDs are what let an engineer find your specific requests, and a report without them almost always comes back with a request for more detail.