Microsoft Azure Workload Monitor

Name: Workload Monitor API
Brand: Workload Monitor
Availability: InStock

★ Only Publicly Available OpenAPI DocumentDeveloper ToolsMonitoring Observabilityoauth213 Endpoints

Install Jentic One Beta

Connect the Workload Monitor to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Workload Monitor, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Workload Monitor API.

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

GET STARTED

Start building with Workload Monitor API

Explore with Jentic

View OpenAPI Document

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

Use for: Get a summary of monitored components across my subscription, List all monitor instances for a specific Azure VM, Retrieve the current health of a workload monitor, Find which components are being monitored on a resource

Not supported: Does not create monitors, raise alerts, or send notifications — use only for reading WorkloadMonitor components, monitor instances, and notification settings.

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.

Use Cases

Patterns agents use Workload Monitor API for, with concrete tasks.

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

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.

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.

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.

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

13 endpoints — 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.

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

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

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

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.

Intent-based discovery

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.

Time to first call

FAQs

Specific to using Workload Monitor API through Jentic.

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.