Is Microsoft Azure down?

Understanding Microsoft Azure availability

Microsoft Azure is a collection of cloud services distributed across regions, subscriptions, resource types, identity systems, and management interfaces. An incident affecting one Azure service or region does not necessarily make every Azure workload unavailable.

Check the official Azure status page first when several unrelated Azure resources fail, an issue starts suddenly, or the same operation fails from multiple networks. Compare any listed incident with the affected service, region, and time. If there is no matching incident, continue investigating the individual resource, deployment, identity configuration, quota, DNS path, private endpoint, or application.

For API and application failures, preserve the HTTP status, complete response, Azure service, region, resource identifier, operation, timestamp, and request or correlation ID. These details help distinguish a platform incident from authentication, authorization, deployment, DNS, timeout, and application problems.

Troubleshooting Microsoft Azure problems

1. Check whether the problem is a wider Azure incident

Open the official Azure status page and look for an event matching the affected service, region, and time. A broader incident is more plausible when unrelated resources or operations fail simultaneously and the same behavior appears from different networks. During an active incident, preserve error details and follow published updates rather than making repeated or destructive changes.

2. If one resource or workload fails

Check the resource’s current state, recent configuration changes, deployment history, dependencies, and service-specific logs. Confirm that the request targets the intended subscription, resource group, region, endpoint, and API version where applicable. A single failed resource is more consistent with a deployment, application, permission, quota, or configuration issue than with a global Azure outage.

3. Separate sign-in from authorization failures

For portal or API authentication problems, verify the tenant, subscription, account, service principal, managed identity, token, and role assignments in use. A 401 response generally indicates an authentication or token problem; a 403 response generally indicates that the identity is authenticated but lacks the required permission. Do not include credentials, access tokens, or secrets in diagnostic reports.

4. Check the browser and Azure management interface

If the problem occurs only in the browser, try a private window or another supported browser. Check for stale sessions, blocked cookies, extensions, and cached application data. Compare the portal with the underlying resource endpoint or a permitted command-line or API operation when possible. If the resource works elsewhere, the browser session or management interface is a more likely cause.

5. Investigate network, DNS, and TLS failures

For timeouts, refused connections, name-resolution failures, or certificate errors, test from a second network and resolve the exact hostname being used. Review corporate proxy, firewall, VPN, private endpoint, routing, DNS, and TLS inspection settings. If public access works but a private or corporate network does not, investigate that network path before changing the Azure resource.

6. Investigate API and deployment failures

Keep the complete response body, HTTP status, operation name, timestamp, region, and request or correlation ID. Treat transient 5xx responses differently from 4xx authentication, authorization, validation, quota, or configuration responses. Retry only when the operation is safe to repeat and use appropriate backoff; not every failed request indicates an Azure outage.