Status Meanings
Plain-language guide
This dashboard is a regional rollout monitor. Most checks are read-only catalog checks: they ask Azure which locations, versions, SKUs, or extension types are advertised by Azure control-plane APIs or Azure CLI commands. They are fast and cheap, but they are not the same thing as a full deployment test.
Region scope
The scheduled full scan uses the monitor's configured public Azure region list, which is refreshed from Azure CLI location metadata as the project evolves. In other words, the dashboard is intended to cover Azure public cloud physical regions in scope for this monitor, but it should not be read as a contractual list of every Azure location, sovereign cloud, private preview region, or capacity cell.
Overall statuses
| Status | Meaning | What it does not prove |
|---|---|---|
| available | The feature was listed or matched by the read-only probe for that region. | It does not guarantee that a later deployment will pass quota, capacity, policy, identity, or provider-registration checks. |
| unavailable | The probe completed successfully, but the feature was absent from the catalog or location list used by that probe. | It does not necessarily mean the service is impossible forever, globally blocked, or failing because of quota. |
| partial | Reserved for checks where some required sub-conditions pass and others fail. | Current read-only probes rarely emit this because they usually test one listed item at a time. |
| unknown | The probe could not produce reliable evidence, usually because Azure CLI failed, timed out, returned invalid JSON, or the provider endpoint was not available. | It should not be treated as unavailable. It means the monitor did not get a trustworthy answer. |
History and signal changes
The recent-history panel highlights only clear availability signals: unavailable to available is a new availability signal, and available to unavailable is a regression signal. Transitions into or out of unknown are parked as probe-quality changes, because they do not prove a rollout or rollback.
Azure Functions Flex Consumption
The hostingPlans.flexConsumption row comes from az functionapp list-flexconsumption-locations --output json. Azure CLI describes this command as listing available locations for running function apps on the Flex Consumption plan.
If a region is absent from that list, the dashboard marks Flex Consumption as unavailable. In plain language, that means Azure did not advertise that region as a Flex Consumption location to this command at scan time. It is not a quota result.
The runtime rows, such as runtimes.python.3.14 or runtimes.node.24, are tied to the Flex location signal. If Flex is not listed for a region, every Functions runtime row is marked unavailable for that region because there is no Flex hosting target in the read-only evidence. If Flex is listed, runtime availability is checked against az functionapp list-runtimes --os linux --output json.
Azure per-region model latency coverage
The Azure Per-Region Latency board only lists regions where an Azure OpenAI model is offered as a single-region Standard deployment. That matters because only a single-region Standard (non-global) deployment is processed in its own account's region, which is what makes a timing attributable to that region. GlobalStandard and DataZoneStandard deployments may be processed in any datacenter in their geography, so timing them would not tell you how fast a specific region is.
This is why many large regions — for example westeurope, northeurope, southeastasia, koreacentral, and centralindia — do not appear even though they clearly host Azure OpenAI. In those regions the models are currently offered only as GlobalStandard / DataZoneStandard / ProvisionedManaged, not as single-region Standard, so there is nothing region-attributable to measure. The monitor scans a broad candidate region list each run and automatically adds any region the moment Azure starts offering a Standard SKU there.
Names like “Asia”, “South Asia”, or “Europe East” are Azure geographies or informal groupings, not deployable region IDs. The comparable real regions are eastasia, southeastasia, centralindia/southindia, and northeurope/westeurope.
Other modalities
| Modality | Available means | Unavailable means |
|---|---|---|
| AKS extensions | The extension type was listed by the AKS extension catalog for the region. | The extension type was absent from the regional catalog, or the regional locations/extensionTypes endpoint reported that the region is outside its supported locations. |
| AKS Kubernetes versions | az aks get-versions listed a Kubernetes version matching the configured prefix. | The version listing succeeded, but no matching version prefix was present. |
| Azure AI models | az cognitiveservices model list --location <region> listed the model/version in the region. | The model/version was not present in the regional catalog, or the regional locations/models endpoint reported that the region is outside its supported locations. |
| Container Apps | az provider show --namespace Microsoft.App --expand resourceTypes/locations advertised the resource type in the region. | The provider metadata call succeeded, but the resource type was not advertised in that region. |
| VM SKUs | Legacy az vm list-sizes --location <region> listed the SKU, or supported az vm list-skus --location <region> --resource-type virtualMachines --all fallback evidence listed it after a failed or suspiciously small legacy listing. | The regional VM SKU listing succeeded, no fallback evidence added the SKU, and the SKU was absent from that regional list. |