Azure separates two kinds of telemetry: platform metrics, which flow into Azure Monitor automatically, and resource logs, which are not collected anywhere until you create a diagnostic setting on the resource. A diagnostic setting is a small routing rule — "send these log categories to that destination" — and until one exists, detailed request-level history for your Foundry resource is simply not retained for you to query. For any production Claude deployment, creating one should be part of resource provisioning, not an afterthought.
Turning it on
In the Azure portal, open your Foundry resource, find the diagnostic settings section under its monitoring options, and add a new setting. You choose three things: a name, which log categories (and optionally metrics) to collect, and one or more destinations. The same configuration can be applied through ARM/Bicep or Terraform, which is the right approach if you provision Foundry resources as code — bake the diagnostic setting into the template so no resource ships without it (see ARM templates for Foundry and Terraform for Foundry).
One honest caveat: Microsoft's Claude-specific documentation does not enumerate the exact log category names Foundry resources expose for Claude deployments. The category list you see in the portal's diagnostic settings blade for your resource is authoritative — review it there or in the current Azure Monitor reference for Foundry, rather than relying on category names from other Azure AI services, which have changed over time.
Choosing a destination
| Destination | Best for | Trade-off |
|---|---|---|
| Log Analytics workspace | Interactive KQL queries, dashboards, alerts | Ingestion and retention costs scale with volume |
| Storage account | Cheap long-term retention for audit and compliance | Not queryable in place; retrieval is manual |
| Event hub | Streaming into an external SIEM or observability platform | You own the downstream pipeline |
These destinations are not mutually exclusive — a common enterprise pattern is Log Analytics for the operations team's day-to-day queries plus a storage account for long-horizon retention. If your security team runs a SIEM, the event hub route lets Claude API activity join the rest of your security telemetry. Whatever you choose, decide retention deliberately: log volume from a busy Claude workload is significant, and Log Analytics pricing is driven by ingested gigabytes.
What the logs will and won't tell you
Expect resource logs to be strongest on operational questions — who called the endpoint, when, with what result code and latency. Two Foundry-specific points to fold into your plan:
- Correlation: Foundry API responses include
request-idandapim-request-idheaders. Capture them in your application logs so you can line up an application-side error with the platform-side record, and hand both to support when escalating. - Token accounting: the definitive token counts for each call are in the API response's
usageobject. If per-request token analysis matters to you (and for cost work it does), logusagefrom your application rather than hoping to reconstruct it from platform logs. - Content: for Azure-hosted Claude deployments, prompts and outputs are processed on Azure infrastructure and Microsoft states data at rest stays in the selected Azure geography. Before routing any log category that could carry request content into a broadly accessible workspace, check what the category actually captures and apply your data-classification rules — log destinations inherit none of the access restrictions of the resource that produced them.
Where to go next
Once logs are flowing into a workspace, querying Foundry logs in Log Analytics covers the analysis side, and monitoring Foundry with Azure Monitor covers metrics and alerting.