Log Analytics is Azure Monitor's query layer: logs land in workspace tables, and you interrogate them with the Kusto Query Language (KQL) — a pipeline-style language where each line filters, summarizes, or reshapes the rows from the previous one. With diagnostic settings routing your Foundry resource's logs to a workspace, the platform side of every Claude call becomes queryable history. This article maps the questions you will actually ask to the data that can answer them — and is candid about which answers need your own application logs instead.
Know your schema before writing queries
Microsoft's Claude-specific documentation does not publish the exact table and column schema that Foundry resource logs produce, and schemas differ across Azure services and log categories. So step one is empirical: open your workspace, look at the tables your diagnostic setting is populating, and inspect a few rows. Build your saved queries against what you find, not against column names copied from another service's tutorial. The patterns below describe the analysis; the identifiers come from your workspace.
The four analyses that earn their keep
| Question | KQL pattern | Data source |
|---|---|---|
| Error and throttle rate | Filter to your resource, bucket by status code, summarize count() by bin(time, 5m) | Platform request logs |
| Latency percentiles | summarize percentiles(duration, 50, 95, 99) per deployment per hour | Platform request logs |
| Token usage and cost drivers | Sum input/output/cache tokens by model, team, or feature | Your application logs (the API usage object) |
| Refusal tracking | Count responses with stop_reason == "refusal", by category | Your application logs |
The split in the last column is the important lesson. Platform logs see the HTTP envelope — timing, status, caller. Only your application sees the response body, and that body carries the two richest signals: the usage object (authoritative input, output, and cache token counts per request) and the stop_reason. If you ingest your application logs into the same workspace (via Application Insights or a custom table), one KQL query can join both worlds through the request-id and apim-request-id headers Foundry returns on every response.
A minimal structured log line from Python gives KQL everything it needs:
import json, logging
from anthropic import AnthropicFoundry
client = AnthropicFoundry(api_key="...", resource="example-resource")
msg = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Summarize this ticket..."}],
)
logging.info(json.dumps({
"model": "claude-sonnet-5",
"stop_reason": msg.stop_reason,
"input_tokens": msg.usage.input_tokens,
"output_tokens": msg.usage.output_tokens,
}))About "content-filter hits"
Teams coming from Azure OpenAI often look for content-filter log entries. For Claude, Foundry works differently: Microsoft states that Foundry provides no built-in content filtering for Claude models at deployment time — Claude deployments rely on Anthropic's safety systems, and customers configure any additional content safety during inference themselves. The queryable safety signal is therefore the model's own refusal behavior. On Claude Fable 5, safety-classifier refusals return HTTP 200 with stop_reason: "refusal" — invisible to a status-code query, which is exactly why logging stop_reason application-side matters. A rising refusal rate is worth an alert: it usually means a prompt change, a misbehaving upstream input, or users probing limits.
request-id.From ad-hoc queries to operational routine
Once the first queries prove useful, promote them: save the error-rate and latency queries as workspace functions so every engineer runs the same definition, pin the results to a shared dashboard, and convert the two or three that matter most into log-based alert rules — a sustained rise in 429s or refusals is worth a page, not a weekly discovery. Keep an eye on workspace cost as well: Log Analytics bills by ingested volume, and a chatty Claude workload can generate more platform log data than you expect. Scope queries to tight time ranges by default, and revisit which log categories you actually query after the first month — anything nobody has queried is a candidate for cheaper storage-account retention instead (see choosing a diagnostic-log destination).
Where to go next
For the metrics-and-alerts side of the same telemetry, see monitoring Foundry with Azure Monitor; for turning the token numbers into dollars, see analyzing Foundry spending.