Cosmos total request units compared to requests

Question

Cosmos total request units compared to requests

Trevor Nichols 0

We have a cosmos account that has extremely high total request units, which do not match the number of requests. The workload drops down to virtually zero over night yet it has been consistently high.

User's image

How can we identify what is causing this total request units so high. I have determined this is Query operations so filtered just for that - we have a lot of queries, sure, but this is a significant mismatch.

Longer term view shows this isn't always happening - it looks like this is correlating as I would expect just before the Tue 05 label

User's image

Pilladi Padma Sai Manisha 7,800 Reputation points Microsoft External Staff Moderator

2026-05-06T03:59:52.14+00:00
Hi Trevor Nichols,
Thankyou for reaching microsoft Q&A!
From what you’ve shown, the main concern is that the RU consumption stays consistently high even when the actual request volume drops significantly overnight. In Cosmos DB, this usually points to a smaller number of queries that are individually expensive rather than simply a large number of requests.

This can commonly happen with:

Cross-partition queries

Queries scanning large amounts of data Missing or inefficient indexing Operations like ORDER BY, DISTINCT, or CONTAINS Background workloads such as Functions, scheduled jobs, or change feed processors continuing to run

Since you already narrowed it down to Query operations, the next step would be identifying which specific queries are consuming the most RUs.

You can use Log Analytics with Cosmos DB diagnostic logs to check this. For example:

CDBDataPlaneRequests | where TimeGenerated > ago(24h) | where OperationName == "Query" | summarize TotalRU = sum(RequestCharge), Requests = count() by DatabaseName, CollectionName, QueryText | order by TotalRU desc

This should help highlight whether a small set of queries is driving most of the RU usage.

Once the high-RU queries are identified, reviewing the query metrics (index hit ratio, retrieved document count, partition usage, etc.) will usually make it clearer whether the queries are performing scans or cross-partition reads.

Helpful docs:

https://learn.microsoft.com/azure/cosmos-db/understand-request-unit-consumption https://learn.microsoft.com/azure/cosmos-db/diagnostic-queries https://learn.microsoft.com/azure/cosmos-db/query-metrics-performance

If you can share sanitized query samples or query metrics from a few of the expensive operations, we can help narrow down the likely cause further.

1 answer

Your answer

Pilladi Padma Sai Manisha 7,800 Reputation points Microsoft External Staff Moderator

2026-05-06T03:59:52.14+00:00

Hi Trevor Nichols,
Thankyou for reaching microsoft Q&A!
From what you’ve shown, the main concern is that the RU consumption stays consistently high even when the actual request volume drops significantly overnight. In Cosmos DB, this usually points to a smaller number of queries that are individually expensive rather than simply a large number of requests.

This can commonly happen with:

Cross-partition queries

Queries scanning large amounts of data Missing or inefficient indexing Operations like ORDER BY, DISTINCT, or CONTAINS Background workloads such as Functions, scheduled jobs, or change feed processors continuing to run

Since you already narrowed it down to Query operations, the next step would be identifying which specific queries are consuming the most RUs.

You can use Log Analytics with Cosmos DB diagnostic logs to check this. For example:

CDBDataPlaneRequests | where TimeGenerated > ago(24h) | where OperationName == "Query" | summarize TotalRU = sum(RequestCharge), Requests = count() by DatabaseName, CollectionName, QueryText | order by TotalRU desc

This should help highlight whether a small set of queries is driving most of the RU usage.

Once the high-RU queries are identified, reviewing the query metrics (index hit ratio, retrieved document count, partition usage, etc.) will usually make it clearer whether the queries are performing scans or cross-partition reads.

Helpful docs:

https://learn.microsoft.com/azure/cosmos-db/understand-request-unit-consumption https://learn.microsoft.com/azure/cosmos-db/diagnostic-queries https://learn.microsoft.com/azure/cosmos-db/query-metrics-performance

If you can share sanitized query samples or query metrics from a few of the expensive operations, we can help narrow down the likely cause further.

Answer 1

This usually points to inefficiencies in the requests, indexing issues, or hidden background operations. Since you’ve already filtered to query operations, the next step would be to dig into the requests and how they’re consuming RUs.

One common cause is queries that scan large amounts of data. Cosmos DB charges RUs based on the work done, not just the number of requests, so a single inefficient query can consume hundreds or thousands of RUs. You should check for queries without proper filters, missing partition keys, or using cross-partition queries unnecessarily.

To investigate further, you can look at the Query Metrics per operation. If you’re using the SDK or the portal, enable x-ms-documentdb-query-metrics for your queries. This will show you metrics such as retrieved document count, scanned document count, and RUs consumed per query. If you see that the retrievedDocumentCount is much lower than totalDocumentCount, that indicates a lot of documents are being scanned unnecessarily.

You can also use the Metrics in Azure Monitor for Cosmos DB to break down RU consumption by operation type, container, and even time windows. Look specifically at the RU per query and partition. Sometimes a single partition can get hot, causing spikes that aren’t apparent if you only look at the number of requests.

Finally, examine if there are any automated processes running around those spikes like batch jobs, change feed processors, or TTL cleanup tasks that might be executing queries inefficiently. These can run even when your normal workload is low and inflate RU usage unexpectedly.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Trevor Nichols 0 Reputation points

2026-05-06T23:42:22.1066667+00:00

I ended up enabling the diagnostic query logging and was analysing all the queries. This enabled me to confirm the software component causing this. One slightly confusing part was the diagnostic logs sanitise the parameters and even property references in the query. Regardless I added logging for high RU queries and after deploying the new version the high load query stopped.

I have narrowed this down to a possible software bug in our software. I am not sure how but it was performing an expensive query in loop. If this happens again I should be able to get the answers from the logging.

Share via

Cosmos total request units compared to requests

1 answer

Your answer