Check Cosmos DB hot partitions before reducing RUs
On this page
Before reducing Cosmos DB throughput, inspect the documented Insights views for Normalized RU Consumption and request status codes. If one range is repeatedly higher than others, use partition-key RU logs and their peak timestamps to correlate concentrated load with normalized RU peaks and 429s.
Why this is worth a look
Azure Cosmos DB distributes provisioned throughput equally across partition key ranges. Normalized RU Consumption is the maximum RU/s utilization across those ranges during each interval, not a container average. Partition-key RU logs add logical-key, physical-range, region, operation, consumed RU, and UTC timestamp detail. Use those signals together because logged Request Units describe request consumption, while normalized utilization describes use of provisioned throughput.
Start with this query
KQLRead-only KQL for a Log Analytics workspace. It summarizes logged Request Units in one-second intervals, then returns total RU, peak one-second RU, and the UTC timestamp of that peak for each logical key, physical range, region, and operation over the preceding hour.
let BySecond =
CDBPartitionKeyRUConsumption
| where TimeGenerated >= ago(1h)
| summarize SecondRU = sum(RequestCharge)
by bin(TimeGenerated, 1s),
AccountName,
DatabaseName,
CollectionName,
RegionName,
PartitionKeyRangeId,
PartitionKey,
OperationName
| project PeakSecond = TimeGenerated,
SecondRU,
AccountName,
DatabaseName,
CollectionName,
RegionName,
PartitionKeyRangeId,
PartitionKey,
OperationName;
let Totals =
BySecond
| summarize TotalRU = sum(SecondRU), PeakSecondRU = max(SecondRU)
by AccountName,
DatabaseName,
CollectionName,
RegionName,
PartitionKeyRangeId,
PartitionKey,
OperationName;
let Peaks =
BySecond
| summarize arg_max(SecondRU, PeakSecond)
by AccountName,
DatabaseName,
CollectionName,
RegionName,
PartitionKeyRangeId,
PartitionKey,
OperationName
| project AccountName,
DatabaseName,
CollectionName,
RegionName,
PartitionKeyRangeId,
PartitionKey,
OperationName,
PeakSecond;
Totals
| join kind=leftouter Peaks on AccountName, DatabaseName, CollectionName, RegionName, PartitionKeyRangeId, PartitionKey, OperationName
| project AccountName,
DatabaseName,
CollectionName,
RegionName,
PartitionKeyRangeId,
PartitionKey,
OperationName,
TotalRU,
PeakSecondRU,
PeakSecond
| order by TotalRU descHow to confirm it
- 01
Open the range-level view
In the Azure Cosmos DB account, navigate to Insights > Throughput > Normalized RU Consumption (%) By PartitionKeyRangeID. Filter the view to the specific database and container. This metric is defined as the maximum RU/s utilization across partition key ranges in each interval, not an average.
- 02
Review request status codes
In Insights > Requests > Total Requests by Status Code, filter to the database and container. Inspect requests with status code 429 and split them by Operation Type, then compare their timing with normalized RU peaks.
- 03
Run the timestamp-preserving query
In the Log Analytics workspace receiving the account's partition-key RU logs, run the KQL command for the preceding one hour. It returns TotalRU, PeakSecondRU, and PeakSecond in UTC, grouped by logical key, physical range, region, and operation. TotalRU and PeakSecondRU are consumed Request Units, not provisioned RU/s.
- 04
Correlate before changing throughput
Start with rows having the greatest TotalRU or PeakSecondRU. Compare each row's PeakSecond timestamp with the normalized RU view and 429 timing. Treat the log results as request-volume attribution, then decide whether reducing throughput is consistent with the observed load and throttling.
Before making changes
Assume the Cosmos DB account already sends the relevant partition-key RU-consumption diagnostic logs to a Log Analytics workspace, preferably in resource-specific mode. Run this read-only query in that workspace with access to the workspace data and review the matching account, database, and container scope. The one-hour window uses TimeGenerated in UTC and excludes activity without a corresponding log record. RequestCharge and the derived totals are consumed Request Units, and this query does not calculate normalized utilization or a 429 rate.