Addressing review comments

Author: tselmegbaasan

modules/ROOT/pages/clustering/monitoring/status-check.adoc

@@ -1,16 +1,15 @@
-:description: This section describes how to monitor a database's availability with the help of the rafted status check
-[role=label--new-5.24]
-== Rafted Status Check
+:description: This section describes how to monitor a database's availability with the help of the cluster status check
+[role=label--new-5.24 label--enterprise-edition]
+[[database-status-check]]
+== Cluster Status Check
 
-Neo4j 5.24 introduces the xref:reference/procedures.adoc#procedure_dbms_cluster_statusCheck[`dbms.cluster.statusCheck()`] procedure, which can be used to monitor the ability to replicate in rafted databases, which in most cases means being able to write to the database. It can also
-be used to check which members are up-to-date and can participate in a successful replication. Therefore, it is useful in determining the fault-tolerance of a rafted database as well. A third and final function is to determine the leader of the raft group.
+Neo4j 5.24 introduces the xref:reference/procedures.adoc#procedure_dbms_cluster_statusCheck[`dbms.cluster.statusCheck()`] procedure, which can be used to monitor the ability to replicate in clustered databases, which in most cases means being able to write to the database. You can also use the procedure to check which members are up-to-date and can participate in a successful replication. Therefore, it is useful in determining the fault-tolerance of a clustered database as well. A third and final function is to determine the leader of the cluster.
 
 [NOTE]
 ====
-The member on which the procedure is called replicates a `status check entry` in the same raft group as the transactions, and verifies that the entry can be replicated and applied.
+The member on which the procedure is called replicates a dummy transaction in the same cluster as the real transactions, and verifies that it can be replicated and applied.
 
-Since the entry is not applied to the transaction state machine, it's not guaranteed that the database is write available even though the status check reports that
-it can replicate. However, it tells that the raft group is healthy and in most cases that means that the database is write available.
+Since the status check doesn't replicate an actual transaction, it's not guaranteed that the database is write available even though the status check reports that it can replicate. Apart from replication there are other stops in the write path that can potentially block a transaction from being applied, e.g. issues in the database. However, it tells that the cluster is healthy and in most cases that means that the database is write available.
 ====
 
 === Syntax
@@ -20,27 +19,22 @@ it can replicate. However, it tells that the raft group is healthy and in most c
 CALL dbms.cluster.statusCheck(databases :: LIST<STRING>, timeoutMilliseconds = null :: INTEGER)
 ----
 
-* *databases:* the list of databases for which the status check should run. Providing an empty list will run the
-status check for all *rafted* databases on that server.
-* *timeoutMilliseconds:* specifies how long the replication may take. Default value is 1000 milliseconds. If replication takes longer than this timeout, it will return that
-replication is unsuccessful.
+* *databases:* the list of databases for which the status check should run. Providing an empty list will run the status check for all *clustered* databases on that server, i.e. the status check won't run on singles or secondaries.
+* *timeoutMilliseconds:* specifies how long the replication may take. Default value is 1000 milliseconds. If replication takes longer than this timeout, it will return that replication is unsuccessful.
 
 
-The procedure returns a row for all raft group members of all the requested databases where each row consists of:
+The procedure returns a row for all primary members of all the requested databases where each row consists of:
 
 * *database:* the database for which the `status check entry` was replicated.
-* *serverId:* the server id of each raft group member, which did or did not participate in a successful replication of the `status check entry`.
-* *serverName:* the server name of each raft group member.
-* *address:* the bolt address of each raft group member.
-* *replicationSuccessful:* indicates if the server (on which the procedure is run) can replicate an entry in raft. Is `TRUE` if this server managed to replicate the `status check entry` to a majority of raft members within the given timeout. `FALSE`
-if it failed to replicate within the timeout. The value is the same column-wise. A failed replication
-can either mean that there is a real issue in the cluster (e.g. no leader) or it may simply mean that this server is too far behind in raft, and can't therefore replicate.
-* *memberStatus:* shows the status of each raft group member. It can either be `APPLYING`, `REPLICATING` or `UNAVAILABLE`. `APPLYING` means that the raft group member has raft running and is actively applying entries, including transactions.
-`REPLICATING` means that the member can participate in replicating, but can't apply. This state is uncommon, but may happen while waiting for the database to start and accept transactions.
-* *recognisedLeader:* shows the server id of the perceived leader of each raft group member.
-* *recognisedLeaderTerm:* shows the term of the perceived leader of each raft group member. If the raft group members report different leaders, the one with the highest term should be trusted.
+* *serverId:* the server id of each primary member, which did or did not participate in a successful replication of the `status check entry`.
+* *serverName:* the server name of each primary member.
+* *address:* the bolt address of each primary member.
+* *replicationSuccessful:* indicates if the server (on which the procedure is run) can replicate a transaction. Is `TRUE` if this server managed to replicate the dummy transaction to a majority of raft members within the given timeout. `FALSE` if it failed to replicate within the timeout. The value is the same column-wise. A failed replication can either mean that there is a real issue in the cluster (e.g. no leader) or it may simply mean that this server is too far behind in apply, and can't therefore replicate.
+* *memberStatus:* shows the status of each primary member. It can either be `APPLYING`, `REPLICATING` or `UNAVAILABLE`. `APPLYING` means that the member can replicate and is actively applying transactions. `REPLICATING` means that the member can participate in replicating, but can't apply. This state is uncommon, but may happen while waiting for the database to start and accept transactions.
+* *recognisedLeader:* shows the server id of the perceived leader of each primary member.
+* *recognisedLeaderTerm:* shows the term of the perceived leader of each primary member. If the members report different leaders, the one with the highest term should be trusted.
 * *requester:* is `TRUE` for the server on which the procedure is run, and `FALSE` on the remaining servers.
-* *error:* contains the error message if there is one. An example of an error is that one of more of the requested databases doesn't exist on the requester.
+* *error:* contains the error message if there is one. An example of an error is that one or more of the requested databases doesn't exist on the requester.
 
 In general the `replicationSuccessful` field can be used to determine overall write-availability, whereas the `memberStatus` field can be checked in order to see whether the database is fault-tolerant or not.