canonical: https://jentic.com/apis/azure.com/workload-monitor # Microsoft Azure Workload Monitor The Azure Workload Monitor API surfaces health monitoring data for workloads running on Azure resources, including components, monitors, monitor instances, and notification settings under the Microsoft.WorkloadMonitor provider. It exposes 13 operations across 11 resource paths covering subscription-wide summaries, per-resource component listings, monitor configuration retrieval, and notification configuration. Use it to inventory monitored components, retrieve health status for individual monitor instances, and roll up workload health into dashboards or alerts. ## For AI agents Inspect Azure Workload Monitor components, monitors, monitor instances, and notification settings to understand the health of monitored workloads and roll the data up to dashboards or agents. ## Scope Does not create monitors, raise alerts, or send notifications - use only for reading WorkloadMonitor components, monitor instances, and notification settings. ## Capabilities - Summarise components and monitor instances across an entire subscription for at-a-glance health - List all components on a specific Azure resource with their current monitoring state - Retrieve monitor and monitor instance details to inspect health status and last evaluation - Read notification settings for a monitored resource to see who gets paged on a state change - Enumerate available WorkloadMonitor operations to drive tooling and discovery ## Use cases ### Workload health dashboard backend Power a workload health dashboard by calling the components and monitor instances summary endpoints to roll up state across an entire Azure subscription. The API returns counts and statuses suitable for high-level dashboards, with per-resource drill-downs available through the components and monitorInstances endpoints. Example prompt: Call componentsSummary and monitorInstancesSummary for subscription 00000000-0000-0000-0000-000000000000 and return the unhealthy counts. ### Per-resource health inspection Drill from a subscription-wide summary into a single resource's monitored components and monitor instances to investigate why a workload appears unhealthy. The components and monitorInstances endpoints scoped to a specific resource provide detailed state per monitored item, supporting root-cause investigation. Example prompt: List components on resource /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/web-01 and return any in an unhealthy state. ### Notification configuration audit Read the notification settings on monitored resources to confirm who receives alerts when monitors change state. The notificationSettings endpoint exposes the configured channels so an agent can audit coverage and flag resources without notifications wired up. Example prompt: Get the notification settings for resource /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/web-01 and report the configured email recipients. ### Agent-driven workload health checks Let an AI agent answer 'is my production workload healthy?' by combining the summary endpoints with the per-resource detail calls through Jentic. This turns a multi-step portal investigation into a single conversational query. Example prompt: Search Jentic for 'azure workload monitor instances summary', load the schema, execute it, and report any subscription with unhealthy instance counts above zero. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | /subscriptions/{subscriptionId}/providers/Microsoft.WorkloadMonitor/componentsSummary | Subscription-wide component summary | | GET | /subscriptions/{subscriptionId}/providers/Microsoft.WorkloadMonitor/monitorInstancesSummary | Subscription-wide monitor instance summary | | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceNamespace}/{resourceType}/{resourceName}/providers/Microsoft.WorkloadMonitor/components | List monitored components on a resource | | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceNamespace}/{resourceType}/{resourceName}/providers/Microsoft.WorkloadMonitor/monitorInstances | List monitor instances on a resource | | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceNamespace}/{resourceType}/{resourceName}/providers/Microsoft.WorkloadMonitor/monitors | List monitors attached to a resource | | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceNamespace}/{resourceType}/{resourceName}/providers/Microsoft.WorkloadMonitor/notificationSettings | Get notification settings for a resource | | GET | /providers/Microsoft.WorkloadMonitor/operations | List available WorkloadMonitor operations | ## Key resources - **ComponentsSummary** — Subscription-wide summary of monitored components - **MonitorInstancesSummary** — Subscription-wide summary of monitor instance health - **Components** — Per-resource list of monitored components - **Monitors** — Monitor definitions attached to a resource - **MonitorInstances** — Live instances of monitors with health state - **NotificationSettings** — Configured notification channels for a resource - **Operations** — List of available WorkloadMonitor REST operations ## Why Jentic - **Setup:** Reading Workload Monitor health by hand means acquiring Azure Active Directory OAuth 2.0 tokens, targeting the management.azure.com ARM control plane, and threading subscription, resource group, and nested resource ids through every Microsoft.WorkloadMonitor path yourself. Through Jentic you install once, import Workload Monitor from the API Directory, store the Azure AD credential once, and your agent calls it. - **Permission scoping:** This API carries the subscription, resource group, and target resource in the URL path (/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceNamespace}/{resourceType}/{resourceName}/providers/Microsoft.WorkloadMonitor/...), so a rule can pin your agent to one resource or resource group and nothing else. The surface is read-only, so the agent can list components, monitor instances, and notification settings but cannot create monitors or raise alerts. - **Credential handling:** Your Azure AD token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'get a workload health summary' or 'list monitor instances for a resource', and Jentic returns the matching WorkloadMonitor operation with its input schema so the agent calls the right ARM endpoint without reading docs. ## Related APIs - **Azure Monitor Management Client** — Production Azure Monitor surface for metrics, logs, and alerts - **Application Insights Management Client** — Manage Application Insights resources alongside workload health - **Azure Alerts Management** — Investigate and manage alerts triggered by workload state changes ## FAQ ### What authentication does the Workload Monitor API use? The API uses Azure Active Directory OAuth 2.0 via the implicit flow scheme `azure_auth`, scoped to user_impersonation against https://management.azure.com. Through Jentic the OAuth token stays in the vault and only short-lived scoped bearer tokens are exposed to the agent. ### Can I get a subscription-wide summary of workload health? Yes. GET /subscriptions/{subscriptionId}/providers/Microsoft.WorkloadMonitor/componentsSummary and the matching monitorInstancesSummary endpoint return rolled-up counts of components and monitor instances by health state across the whole subscription. ### What are the rate limits for this API? The spec does not declare explicit rate limits. Calls go through Azure Resource Manager, which applies standard ARM throttling per subscription. Inspect the x-ms-ratelimit-remaining-subscription-reads response header to track quota. ### How do I list monitor instances on a specific VM through Jentic? Search Jentic for 'list azure workload monitor instances on a resource', load the schema for GET /subscriptions/{sub}/resourceGroups/{rg}/providers/{ns}/{type}/{name}/providers/Microsoft.WorkloadMonitor/monitorInstances, and execute it. Install with `pip install jentic` and use the async search/load/execute pattern. ### Does this API let me create new monitors? No. The 2018-08-31 preview surface is read-oriented: you can list and get components, monitors, monitor instances, and notification settings, but the spec does not include create or update operations for monitors themselves. New monitors are created through the broader Azure Monitor configuration. ### Is this API GA or still in preview? It is the 2018-08-31 preview version. Treat workflows depending on it as preview-grade and prefer the production Azure Monitor APIs for long-lived automation. ### Can I limit what my agent is allowed to do with the Workload Monitor API? Yes. Because you run Jentic One yourself, your own rules decide which Workload Monitor operations and credentials the agent may use. This API carries the subscription, resource group, and target resource directly in each Microsoft.WorkloadMonitor URL path, so a rule can pin the agent to a single resource or resource group and nothing else. The surface is read-only, so the agent can list components, monitor instances, and notification settings but cannot create monitors or raise alerts.