429 throttling on cosmos db account (test)

Hi @Andre Ferreira

it looks like you’re hitting “Request Rate Too Large” (HTTP 429) errors on your Cosmos DB test account during write-heavy workloads. That usually means you’re exceeding the provisioned RU/s (or hitting a hot‐partition, metadata or transient issue). Here’s a quick checklist to help you diagnose and mitigate:

Analyze throttling patterns • In the Azure portal, go to Monitor → Metrics → Total Requests by Status Code and filter for 429. • Check the x-ms-retry-after-ms (or Retry-After) header to see how long the service suggests you wait before retrying. • If you’ve enabled diagnostic logs, query AzureDiagnostics for 429 entries and aggregate by operationType and RU consumption.

Identify hot partitions • Navigate to your Cosmos DB account → Insights → Partition Key Metrics (or Throughput → Normalized RU Consumption by PartitionKeyRangeID). • Look for any partition key that’s consistently near 100% usage.

Right‐size your throughput • If you’re on manual throughput, consider bumping up the RU/s temporarily to absorb peak loads. • If you’re on autoscale, verify your max RU/s setting and observe if it spikes quickly enough for your workload.

Implement or tune retry/backoff logic • In your Cosmos DB SDK, configure exponential backoff. For .NET for example:

var options = new CosmosClientOptions {
  MaxRetryAttemptsOnRateLimitedRequests = 5,
  MaxRetryWaitTimeOnRateLimitedRequests = TimeSpan.FromSeconds(60)
};
var client = new CosmosClient(connString, options);

• Always respect the Retry-After header before retrying.

Optimize your data model & indexing • Make sure you have an even partition-key distribution. If you’re persistently hot, you might need to re-partition (create a new container with a better key). • Limit indexing to only the properties you need to reduce RU charge on writes.

Reduce metadata calls • Use a singleton CosmosClient/DocumentClient instance across your app. • Cache database/container names and avoid listing or reading containers/databases on every operation.

Watch for transient service issues • Rare backend hiccups can cause brief 429 spikes. If you suspect that, monitor for >5 minutes and then open a support case if it doesn’t self-heal.

Hope that helps you get your test environment smoothed out! If you need more targeted advice, could you share:

Current RU/s allocation (manual or autoscale max)? Approximate RU/s consumption during peaks? Your partition-key strategy and whether you suspect a hot partition? SDK/language you’re using and your retry/backoff config? Reference links

Diagnose and troubleshoot “Request rate too large” (429) exceptions https://learn.microsoft.com/azure/cosmos-db/nosql/troubleshoot-request-rate-too-large Optimize cost and throughput in Azure Cosmos DB https://learn.microsoft.com/azure/cosmos-db/optimize-cost-throughput Partitioning in Azure Cosmos DB https://learn.microsoft.com/azure/cosmos-db/partitioning-overview Azure Cosmos DB capacity planner https://learn.microsoft.com/azure/cosmos-db/capacity-planner

• Azure Monitor Metrics for Cosmos DB https://learn.microsoft.com/azure/azure-monitor/essentials/data-platform-metrics
• Azure Resource Manager throttling limits https://learn.microsoft.com/azure/azure-resource-manager/management/request-limits-and-throttling