How to measure replica health metric in Azure Cosmos DB for MongoDB vCore

Akunuri, Vithal 20 Reputation points
2026-10-26T13:14:15.5566667+00:00

We have created a read replica for Azure CosmosDB for MongoDB vCore cluster in order to segregate traffic between batch jobs and online traffic. Since our application is deployed on AKS , the read replica is also created in the same region as the writer instance.

What are the SLAs for replication lag and how to monitor it for production workloads ? Below is the information shared by automated help in the portal.

The key issue is that this Azure Cosmos DB for MongoDB vCore resource does not expose a native writer-to-reader replication lag or replica-health metric in Azure Monitor, and Azure Resource Health is not available for this resource type. As a result, the lag between writer and reader cannot be directly measured from the available platform signals, so the problem is a monitoring limitation rather than an observed platform fault.

Azure Cosmos DB
Azure Cosmos DB

An Azure NoSQL database service for app development.

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Rukshan edirisinghe 2,365 Reputation points
    2026-10-26T13:55:45.0866667+00:00

    Hi @Akunuri, Vithal

    On the SLA part first: replication to a vCore replica is asynchronous. Writes on the primary are confirmed without waiting for the replica, and the replication docs don't give a lag SLA or RPO. Lag grows under heavy write load and shrinks when the replica keeps up, so for batch jobs you should plan for "eventually consistent, usually close".

    For monitoring, I'd combine the platform view with a direct measurement from your app:

    1. Platform view: Microsoft's replication troubleshooting guide says to check current replication lag on the Metrics page of the replica cluster. Open the replica (not the primary) in the portal, go to Metrics, and pin whatever replication or lag metric it offers to a dashboard with an alert rule.
    2. Heartbeat measurement: Have a small job in AKS write a document like { _id: "heartbeat", ts: <now> } to the primary every few seconds.
    3. Read that same document from the replica connection string and compute now - ts. That's your real lag as your batch jobs see it. Send it to Application Insights or Prometheus.
    4. Alert when the heartbeat lag stays above the freshness your batch jobs can tolerate.
    5. If lag stays high under load, scale up the replica tier so it can apply writes faster.

    How fresh does the data on the replica need to be for your batch jobs: seconds or minutes?

    If this gives you the visibility you need, please consider accepting it as the answer. If the replica's Metrics page doesn't show any lag metric, let me know and I'll be happy to keep helping.

    Reference:

    Was this answer helpful?

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.