**TL;DR:** Symptom: Cosmos DB 429: request rate too large, RU/s exhausted Cause: The container's provisioned RU/s is below what the workload asks for. 429 with a RetryAfterMs header is throttling, not an outage; the fix is query efficiency or more throughput, not retries alone. CONFIRM IT CONFIRM: portal metrics show normalized RU consumption at 100% on the throttled partition; SDK response headers carry the request charge and retry-after. Check whether one hot partition key drives it (uneven partition distribution).

## The fix

SYMPTOM
Cosmos DB 429: request rate too large, RU/s exhausted

CAUSE
The container's provisioned RU/s is below what the workload asks for. 429 with a RetryAfterMs header is throttling, not an outage; the fix is query efficiency or more throughput, not retries alone.

CONFIRM IT
CONFIRM: portal metrics show normalized RU consumption at 100% on the throttled partition; SDK response headers carry the request charge and retry-after. Check whether one hot partition key drives it (uneven partition distribution).

FIX
FIX: short term: honor retry-after with backoff (the SDK does this by default - do not disable it). Real fix: add a partition-key filter to cross-partition queries, or raise RU/s (`az cosmosdb sql container throughput update`), or enable autoscale. For a hot partition, the partition key design is wrong and needs a migration.

VERIFY
VERIFY: normalized RU consumption drops below 70% at peak and 429s stop in metrics.

## When to use this

- This covers exactly what the title says: Diagnose.
- You are setting this up for the first time, or auditing an existing setup.
- You want the key gotchas in one place before you start.

## When not to use this

- You are doing a different workflow with Diagnose; these steps are specific to the title above.
- You need the full reference docs; this is the short path, not the manual.

## Compatibility

- Not pinned to a specific version; follows current Diagnose behavior.