The connected-user timestamp is 2024-07-16 15:49:58. My understanding is that this timestamp represents the last time the user successfully connected to the server while attempting a replication.
The replication-count timestamp is 2025-08-20 13:15:14. My understanding is this timestamp represents the most recent server-side completion of any /api/v1/initial-replication/get-ids, /api/v1/replication/get-ids, or /api/v1/users-inforequests.
In this case, there is more than a year between the connection and the replication completion. Is my understanding of this metric off? How should I interpret this?
Similarly, if I look at the rev values in these two documents. Can I loosely interpret the value in connected-users as the number of times the user tried to replicate? Can I loosely interpret the rev in the replication-count doc as the number of times those replication requests succeeded?
I created a new user which takes a while to replicate. I logged in and the user is sitting at the Polling replication data… step during bootstrap. I’m looking for their connected-user- document to better understand when this document is created and refreshed. I would expect it to be created once the server started processing the initial replication. That said, I’ve waited for over 10 minutes of initial replication and the user doesn’t appear to yet have a connected-user document.
Is there documentation somewhere on what this connected-user- document is meant to represent? Is it only refreshed on _session requests and it has no connection to replication attempts?
Apologies for my ignorance. How can I know if a heavy user (eg. 200k docs) is attempting replications but unable to complete them because there are too many documents for the server to process?
The connected-user document gets created when the user calls the _session endpoint or the dbinfo endpoint. There is no direct correlation between calling get-ids and connected-user.
The connected-user is meant to represent the user accessing the application. The _session and dbinfo endpoints are called when the application is launched, but not afterwards. So these are inherently connected to the CHT web application being used.
The replication-count document does have a correlation with get-ids, but with some caveats:
it only gets written when there is a difference of at least 100 documents compared to the previous doc
it requires the get-ids internal calls to succeed (which would make the actual get-ids call succeed as well.
Similarly, if I look at the rev values in these two documents. Can I loosely interpret the value in connected-users as the number of times the user tried to replicate?
No. You can loosely interpret this as how many times the user booted the application.
Can I loosely interpret the rev in the replication-count doc as the number of times those replication requests succeeded?
No. Because the document only gets written when there is more than a 100 difference in doc count.