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

CLOUD - Semih BAY 0 Reputation points
2026-09-01T10:55:26.8766667+00:00

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.

Azure Cosmos DB
Azure Cosmos DB

An Azure NoSQL database service for app development.

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Himaja Y 555 Reputation points Microsoft External Staff Moderator
    2026-10-03T09:05:01.35+00:00

    Hi @CLOUD - Semih BAY ,

    Issue Summary

    You reported increased latency on the CustomerDB.RefreshToken collection hosted on Azure Cosmos DB API for MongoDB in the West Europe region. Although the collection was configured with Autoscale RU/s and throughput was increased from 800-8000 RU/s to 1000-10000 RU/s, the application continued experiencing elevated response times, with Datadog traces showing end-to-end durations of approximately 10.2 seconds.

    Investigation Performed

    During our investigation, we reviewed:

    • Azure Cosmos DB performance metrics and backend telemetry.
    • Activity IDs and corresponding request durations provided by your team.
    • Datadog traces showing the application request flow.
    • MongoDB diagnostic logs from the beymen-log Log Analytics workspace.
    • MongoDB C# Driver version 2.13.2.0 used by the application.

    Our analysis confirmed:

    • No sustained RU/s exhaustion was observed.
    • No 429 (rate limiting/throttling) events were identified.
    • All reviewed requests completed successfully with ErrorCode = 0.
    • Cosmos DB server-side latency remained within expected ranges.
    • Increasing RU/s did not improve the observed latency.
    • The MongoDB operation durations were generally in the 2.0-2.6 second range, while Datadog reported approximately 10.2 seconds end-to-end latency.

    Recommendations Provided

    Based on the findings, we recommended reviewing:

    • Application-side processing before and after database operations.
    • Query patterns and indexing strategy for the RefreshToken collection.
    • MongoDB driver connection pool configuration and behavior.
    • Client-side retry and timeout settings.
    • Network connectivity between the application and Cosmos DB.
    • End-to-end application profiling and tracing to identify where additional latency is introduced.

    Conclusion

    Based on all diagnostics, logs, metrics, and traces reviewed, we did not identify evidence of a Cosmos DB platform-side performance issue. The available data indicates that throughput capacity was sufficient, no service-side throttling occurred, and backend latency remained within normal limits.

    The findings suggest that a significant portion of the observed latency is likely occurring outside the Azure Cosmos DB service boundary, potentially within the application layer, networking path, client-side processing, or related components.

    Was this answer helpful?

    0 comments
  2. Allan Solomon Mejia 10,225 Reputation points
    2026-09-02T16:49:03.2533333+00:00

    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.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.