canonical: https://jentic.com/apis/azure.com/microsoft-resourcehealth

# Microsoft Azure Microsoft.ResourceHealth

Jentic publishes the only available OpenAPI specification for Microsoft.ResourceHealth, keeping it validated and agent-ready. The Resource Health API exposes the current and historical availability state of every Azure resource in a subscription, alongside platform-emerging issues that affect entire services or regions. Operators and AI agents can query availability statuses for individual resource URIs, list child availability statuses for parent resources like virtual machine scale sets, and surface emerging issues directly into incident response workflows. Status values include Available, Unavailable, Degraded, and Unknown, with reason codes that explain platform-initiated outages versus user-initiated downtime.

## For AI agents

Query the Azure platform health of any resource and surface emerging service issues. Covers 10 endpoints for availability statuses on individual resources, child resources, subscriptions, and resource groups, plus tenant-wide emerging issue feeds.

## Scope

Does not handle metric collection, log queries, or remediation actions - use for reading Azure platform availability state and emerging issues only.

## Capabilities

- Retrieve the current availability status of any Azure resource by resource URI
- List historical availability status transitions for a resource over time
- Surface child availability statuses for parent resources such as VM scale sets
- List availability statuses scoped to a subscription or resource group
- Query Azure-wide emerging issues affecting one or more services or regions
- Distinguish platform-initiated downtime from customer-initiated downtime via reason codes
- Expose Resource Health operations metadata for self-describing tooling

## Use cases

### Automated incident triage for Azure workloads

When an alert fires on a production workload, an SRE agent calls the Resource Health API to determine whether the cause is platform-initiated or customer-initiated. The current availability status returns a reason code such as PlatformInitiated or Unplanned, allowing the on-call workflow to route platform issues to Azure support and customer issues to the application team. This typically cuts mean time to triage from 15 minutes to under one minute.

Example prompt: Get the current availability status for the virtual machine at /subscriptions/abc/resourceGroups/prod/providers/Microsoft.Compute/virtualMachines/web01 and return the reason code if the status is not Available.

### Subscription-wide health dashboards

Platform teams build live health dashboards by polling the availability statuses endpoint scoped to a subscription. The API returns the latest known status for every resource in the subscription, which a dashboard groups by resource type, region, and reason code. Combined with emerging issues, this produces a single pane of glass that shows both customer impact and Microsoft-acknowledged service incidents.

Example prompt: List availability statuses for subscription abc and return the count of resources in each status bucket grouped by reason code.

### Emerging issue surfacing for status pages

Public-facing status pages and internal communications channels can pull from /providers/Microsoft.ResourceHealth/emergingIssues to surface acknowledged Azure platform issues before customers notice impact. The endpoint returns issue titles, impacted services, regions, and recommended actions, which a content agent can summarize into a customer-facing post within seconds of Microsoft publishing the issue.

Example prompt: List all emerging issues, filter to those impacting the East US region, and produce a one-paragraph summary for each issue.

### Agent-driven Azure platform health checks

AI agents can use Jentic to discover Resource Health operations by intent, load the structured input schema, and execute calls against management.azure.com without browsing the Azure REST docs. Agents can answer is my Azure environment healthy with a single intent search, fetch availability statuses across the subscription, and summarize unhealthy resources in plain English for an on-call engineer.

Example prompt: Search Jentic for list azure availability statuses, load the input schema, and execute it for subscriptionId abc, returning a markdown table of unhealthy resources.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /{resourceUri}/providers/Microsoft.ResourceHealth/availabilityStatuses/current | Get the current availability status for a resource |
| GET | /{resourceUri}/providers/Microsoft.ResourceHealth/availabilityStatuses | List historical availability statuses for a resource |
| GET | /{resourceUri}/providers/Microsoft.ResourceHealth/childAvailabilityStatuses | List child availability statuses for a parent resource |
| GET | /subscriptions/{subscriptionId}/providers/Microsoft.ResourceHealth/availabilityStatuses | List availability statuses across a subscription |
| GET | /providers/Microsoft.ResourceHealth/emergingIssues | List Azure-wide emerging platform issues |

## Key resources

- **Availability Statuses** — Current and historical health status for any Azure resource, scoped by resource URI, resource group, or subscription.
- **Child Availability Statuses** — Health statuses for child resources of a parent, such as instances within a virtual machine scale set.
- **Emerging Issues** — Tenant-wide feed of Microsoft-acknowledged Azure platform issues and outages with impacted services and regions.
- **Operations** — Self-describing metadata for the Resource Health resource provider operations.

## Why Jentic

- **Setup:** Wiring Microsoft.ResourceHealth by hand means implementing Azure AD OAuth 2.0, minting an ARM-scoped bearer token for management.azure.com, URI-encoding each target resource path, and handling ARM read throttling yourself. Through Jentic you install once, import Microsoft.ResourceHealth from the API Directory, store the Azure AD credential once, and your agent calls it.
- **Permission scoping:** The API puts the target resource URI and subscription in the URL path, so a rule can pin your agent to reading availability statuses for one subscription and nothing else. Every operation here is read-only, so you limit the agent to the availability status and emerging issue reads it needs and it cannot change any resource.
- **Credential handling:** Your Azure AD credential is stored once, encrypted, by your own Jentic One instance and exchanged for a short-lived ARM-scoped bearer token at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'check Azure resource availability status' or 'list Azure emerging platform issues', and Jentic returns the matching Resource Health operation with its input schema so the agent supplies the resource URI or subscription and executes.

## Related APIs

- **Azure Monitor** — Provides metric and log telemetry that complements the binary health states from Resource Health.
- **Azure Resource Health Metadata** — Returns metadata describing the structure of availability status reason codes used by Resource Health.
- **Application Insights** — Application-level health and dependency telemetry for instrumented apps, rather than platform-level resource health.

## FAQ

### Why is there no official OpenAPI spec for Microsoft.ResourceHealth?

Microsoft Azure does not publish an OpenAPI specification for the Microsoft.ResourceHealth Resource Provider. Jentic generates and maintains this spec from the Azure Resource Manager contracts so that AI agents and developers can call Microsoft.ResourceHealth via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Microsoft Resource Health API use?

The API uses Azure Active Directory OAuth 2.0 with the user_impersonation scope against https://login.microsoftonline.com/common/oauth2/authorize. Jentic stores the AAD client secret or service principal credentials encrypted in its vault and issues scoped bearer tokens to agents at execution time without revealing the underlying credential.

### Can I get the availability status of a single resource through the Resource Health API?

Yes. Call GET /{resourceUri}/providers/Microsoft.ResourceHealth/availabilityStatuses/current with the URI-encoded resource path as resourceUri. The response includes the status (Available, Unavailable, Degraded, Unknown), a reason type (PlatformInitiated, UserInitiated, Unplanned), and a reasonChronicity that distinguishes transient from persistent issues.

### What are the rate limits for the Microsoft Resource Health API?

Resource Health follows the standard Azure Resource Manager throttling limits, which apply per subscription and per region. Read operations are limited to 1200 requests per hour per subscription. The emerging issues endpoint is global and shares the tenant read budget, so dashboards should cache responses for at least 60 seconds rather than poll continuously.

### How do I list emerging Azure platform issues through Jentic?

Search Jentic for list azure emerging issues, load the schema for GET /providers/Microsoft.ResourceHealth/emergingIssues, and execute the call. Jentic handles AAD token exchange and returns the active issue list, which an agent can then filter by impacted service or region.

### Does the Resource Health API trigger remediation actions?

No. Resource Health is read-only and reports state rather than acting on it. Pair it with the Azure Automation, Logic Apps, or compute resource APIs when an agent needs to restart, redeploy, or failover an unhealthy resource based on the status returned here.

### Can I limit what my agent is allowed to do with the Microsoft Resource Health API?

Yes. Because you run Jentic One yourself, your own rules decide which Resource Health operations and credentials the agent may use. Since this API carries the target resource URI and subscription in the URL path, you can pin the agent to reading availability statuses for a single subscription and nothing beyond it. Every operation here is read-only, so you can restrict the agent to the availability status and emerging issue reads it needs, and it cannot change any Azure resource.