Azure status

How we check Azure

We watch management.azure.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

Azure is dozens of independently operated services, so no single URL proves the whole platform is up. We watch Azure Resource Manager, the control plane that the CLI, SDKs, Terraform, and the portal all go through to manage anything, and pin the specific response an anonymous request receives rather than assuming a 2xx.

What is Azure?

Azure is a large collection of independently operated services, not a single system, spanning compute, storage, databases, identity, and AI infrastructure under one portal and one subscription model. That structure matters before treating any single check of "Azure" as meaningful, because the platform mostly fails one service or one region at a time rather than as a whole.

Azure Resource Manager is the closest thing Azure has to a shared front door, which is why this page watches it instead of the marketing site. Nearly every way of managing Azure resources, whether the CLI, an SDK, Terraform, or the portal itself, goes through ARM to create, read, or change anything, which makes it a more honest signal of whether the platform's control plane is reachable than a page that only describes the company. It remains one layer among many, and it says nothing definitive about the data plane of any individual service actually serving traffic.

The second property worth understanding is how isolated a region or a zone actually is. Most applications run in a handful of regions rather than all of them, and Azure's own architecture treats availability zones within a region as largely independent failure domains for services that support them. An incident affecting one zone or one region leaves the rest of the platform untouched, which is why two teams can report entirely different experiences during the same announced event without either being wrong.

Throttling and permission errors are the most common source of trouble that gets mistaken for an outage. Azure APIs enforce limits scoped to a subscription or resource, and crossing one produces an error from a service that remains completely healthy. The same is true of role-based access control: a role assignment changed during unrelated security work will produce access-denied errors that look exactly like a platform failure and have nothing to do with one. Both are configuration questions, not incidents, and neither will ever appear on a status page because nothing is actually down.

The practical approach to depending on Azure is to treat availability as scoped to the service, region, and subscription actually in use, not as one number for the whole platform. Azure Service Health reports incidents at that granularity, tailored to your own resources, and is the authoritative source during any real event. What an external probe against the control plane adds is an independent baseline that keeps running whether or not Microsoft has published an update yet.

Frequently asked questions

Is Azure down right now?

Check the board above; it reflects our own probes against Azure Resource Manager from all five of our regions, refreshed every couple of minutes. That is the control plane most tooling goes through, not a reading of every Azure service.

My application uses Azure but this page shows it up. What should I check?

Check Azure Service Health for the specific service, region, and subscription your application depends on, because incidents are almost always scoped to one service rather than the whole platform. A quota limit, a role assignment changed during unrelated work, or a regional event will all produce failures while Azure broadly reports healthy.

Does an Azure region outage affect every customer?

No. Azure regions, and often availability zones within a region, operate largely independently, and most applications run in a small number of them rather than all. An incident in a region you do not use will not touch you, which is why reports during any Azure event can disagree without either side being wrong.

Is Azure Service Health the same as this page?

No. Service Health reports what Microsoft has confirmed internally, scoped to your own subscription and resources, which is more relevant to you than any outside probe could be. This page reports what our own probes measured from outside Azure's infrastructure, on a fixed schedule, whether or not Microsoft has published anything yet.

I am getting a 429 or throttling error from an Azure API. Is that an outage?

No, that response means the service answered and is enforcing a limit tied to your subscription or resource. Requesting a limit increase, adding retry with backoff, or spreading requests across more resources fixes it, and nothing about a throttled request points at Azure itself being unwell.