Cosmos DB: Elevated latency in refrehtoken container — Request analysis and troubleshooting steps

Question

Cosmos DB: Elevated latency in refrehtoken container — Request analysis and troubleshooting steps

CLOUD - Semih BAY 0

Problem description

I am experiencing elevated request latency (~3 seconds per request) against the 'refreshtoken' container in my Azure Cosmos DB SQL API account located in West ***. The latency issues began on August 31, 2026, at 07:00 UTC+03:00, despite the container operating with autoscale throughput set initially at 800–8,000 RU/s, later increased to 1,000–10,000 RU/s. The container consumes approximately 800 RU/s, and I connect via Gateway mode over HTTP. I am seeking assistance to identify the root cause of the latency.

Environment

Azure Cosmos DB SQL API account in West Europe, using autoscale throughput (initially 800–8,000 RU/s, later 1,000–10,000 RU/s), connected in Gateway mode over HTTP, single-region deployment.

What I've already tried

I increased the autoscale RU/s range from 800–8,000 to 1,000–10,000, but the container continued to consume about 800 RU/s, and latency remained around 3 seconds. No further diagnostics such as metrics review, partition analysis, or configuration checks have been documented.

Current status

I am seeking guidance on how to analyze server-side metrics, diagnose potential causes such as hot partitions, network latency, or query patterns, and implement troubleshooting steps to reduce request latency in my Cosmos DB container.

Himaja Y 375 Reputation points Microsoft External Staff Moderator

2026-09-01T11:28:08.2333333+00:00

Hi @CLOUD - Semih BAY ,

Could you please share the requested details via private chat to help us investigate this issue further?

1 answer

Your answer

Himaja Y 375 Reputation points Microsoft External Staff Moderator

2026-09-01T11:28:08.2333333+00:00

Hi @CLOUD - Semih BAY ,

Could you please share the requested details via private chat to help us investigate this issue further?

Answer 1

Hello @CLOUD - Semih BAY

Since increasing autoscale throughput didn't change the ~3-second latency and consumption remains around 800 RU/s, don't assume that this is simply insufficient provisioned RU/s.

Start with Cosmos DB → Insights/Metrics and compare Server Side Latency (Gateway) with end-to-end latency. If server-side latency is low while the application still sees ~3 seconds, investigate the client/network path instead.

Also check Normalized RU Consumption by PartitionKeyRangeId rather than total RU usage. A hot partition can reach 100% and throttle even when overall RU consumption appears low.

Enable diagnostic logs temporarily and examine DataPlaneRequests, PartitionKeyRUConsumption, and QueryRuntimeStatistics to identify slow/high-RU queries, 429s, and uneven partition activity.

Finally, if the application supports it, test Direct mode from a client in or near West Europe. Microsoft recommends Direct mode for best Cosmos DB performance because it avoids the Gateway intermediary.

References:

Monitor server-side latency

Cosmos DB diagnostic queries

Those checks should tell you whether the delay is service-side, partition/query-related, or client/network-related before increasing RU/s further.

Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.