Clarify database health status (#2370) (#2379)

Co-authored-by: Nick Giles <[email protected]>

Author: NataliaIvakina

modules/ROOT/pages/clustering/monitoring/endpoints.adoc

@@ -145,8 +145,9 @@ Therefore, details such as `leader` and `raftCommandsPerSecond` are database-spe
 --------------
 ====
 
+[[status-endpoint-descriptions]]
 .Status endpoint descriptions
-[options="header", cols="2,1,1,2,4"]
+[options="header", cols="2,1,1,2,4a"]
 |===
 | Field                          | Type     |Optional| Example                                | Description
 | `core`                         | boolean  | no     | `true`                                 | Used to distinguish between if the server is hosting the database in primary (core) or secondary mode.
@@ -158,7 +159,15 @@ Therefore, details such as `leader` and `raftCommandsPerSecond` are database-spe
 | `votingMembers`                | string[] | no     | `[]`                                   | A member is considered a voting member when the leader has been receiving communication with it.
 
                                                                                               List of member's `memberId` that are considered part of the voting set by this primary.
-| `isHealthy`                      | boolean  | no     | `true`                                 | Reflects that the local database of this member has not encountered a critical error preventing it from writing locally.
+| `isHealthy`                      | boolean  | no     | `true`                                 | Indicates that the local database on this cluster member has not encountered a critical error that can block database operation.
+
+[CAUTION]
+====
+The `isHealthy` status applies only to this member's local database.
+It does not reflect the overall health of the database if it is clustered.
+
+A cluster member may still report `"isHealthy": true` even if the database currently has no leader and so cannot accept write transactions.
+====
 | `memberId`                     | string   | no     | `30edc1c4-519c-4030-8348-7cb7af44f591` | Every member in a cluster has it's own unique member id to identify it.
                                                                                               Use `memberId` to distinguish between primary and secondary servers.
 | `leader`                       | string   | yes    | `80a7fb7b-c966-4ee7-88a9-35db8b4d68fe` | Follows the same format as `memberId`, but if it is null or missing, then the leader is unknown.
@@ -171,6 +180,8 @@ It is recommended to use the metric `<prefix>.clustering.core.commit_index` on e
 
 After an instance has been switched on, the status endpoint can be accessed in order to make sure all the guarantees listed in the table below are met.
 
+
+
 To get the most accurate view of a cluster it is strongly recommended to access the _status endpoint_ on all primary members and compare the result.
 The following table explains how results can be compared.