On Anthropic's first-party API, clients can read anthropic-ratelimit-* response headers to see how close they are to their limits. Anthropic's Foundry documentation is explicit that Foundry does not return these headers — you are told to manage rate limiting via Azure monitoring tools and exponential backoff on 429 responses. That single fact reorganizes your observability plan: the signals you would normally read per-request now have to come from platform monitoring.
Three layers of signal
1. The Foundry portal's Monitoring tab. Microsoft's billing documentation points here for per-model token and request detail — the breakdown that Azure Cost Management's single CCU line cannot give you. This is the first stop for "which deployment is generating the traffic?" and for baselining volumes before you set alert thresholds.
2. Azure Monitor on the Foundry resource. Foundry resources participate in Azure Monitor like other Azure resources, so platform metrics and metric-based alerts are configured on the resource in the Azure portal. One caution born of honesty: Microsoft's Claude-specific documentation does not enumerate the exact metric names and dimensions Claude deployments emit, so check the metrics blade of your own resource (or the current Azure Monitor reference for Foundry) rather than building dashboards from assumed names. The categories worth looking for are the universal ones — request counts, error rates by status code, and latency.
3. Your own application telemetry. Every Claude response includes a standard usage object with exact token counts, and Foundry responses carry two tracing headers — request-id and apim-request-id — which Anthropic asks you to provide to support so an issue can be traced across Anthropic and Azure systems. Log all three on every call. Application-level logging is the only place you can join tokens, latency, model, and business context in one record, which is what makes Log Analytics queries useful later.
What to alert on
| Signal | Why it matters | Alerting approach |
|---|---|---|
| 429 (throttling) rate | You are hitting RPM or ITPM quota; with no rate-limit headers, 429s are your first hard evidence | Alert on any sustained 429s in production; investigate quota vs. traffic shape |
| Request volume | Cost is tokens; volume anomalies precede bill anomalies by weeks | Alert on deviation from baseline, both spikes and unexpected silence |
| Latency (p95 and up) | Long-context and thinking-heavy requests are slow by design; a shift in p95 usually means a workload change | Threshold from your own baseline per model, not a generic number |
| Non-429 errors (4xx/5xx) | 400s can mean a feature unsupported on your hosting option — requests for Anthropic-hosted-only features against an Azure-hosted deployment return 400 by design | Alert on error-rate change; triage by status code |
On thresholds: Foundry quotas are measured in requests per minute and uncached input tokens per minute (ITPM counts uncached input plus cache-write tokens; output and cache reads do not count). Default pay-as-you-go limits are modest — 40 RPM / 40,000 ITPM for Opus-family and Sonnet 5 — so a production workload should know its quota and alert well before typical traffic reaches it. Quota context is covered in Foundry quota types.
Dashboards that answer questions
Resist the wall-of-charts dashboard. A useful Foundry board answers four questions at a glance: Is traffic normal? (request volume vs. baseline) Are we being throttled? (429 count) Are users waiting? (latency percentiles) Is anything failing? (error rate by code). Add a fifth panel for token volume from your application logs, since tokens — not requests — are what converts to cost. For deeper forensics, route resource logs to a Log Analytics workspace via diagnostic settings and query with KQL.
request-id and apim-request-id of an affected call. If your logging captures them, every escalation gets shorter.Where to go next
Turn on diagnostic logs to make these signals queryable, then build the queries in querying Foundry logs in Log Analytics.