# Azure status

> Is Azure down? Live status for Microsoft Azure, uptime history, and per-region response times from our own probes every 2 minutes.

Published: 2026-09-02 | Canonical: https://yoping.me/status/azure

## 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.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/azure. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## 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.