diff --git a/modules/release-notes/partials/docs-server-7.6.2-release-note.adoc b/modules/release-notes/partials/docs-server-7.6.2-release-note.adoc
index 2e2610ef72..dd882289dd 100644
--- a/modules/release-notes/partials/docs-server-7.6.2-release-note.adoc
+++ b/modules/release-notes/partials/docs-server-7.6.2-release-note.adoc
@@ -1,6 +1,6 @@
-== Release 7.6.2 (June 2024)
+== Release 7.6.2 (July 2024)
 
-Couchbase Server 7.6.2 was released in June 2024. This maintenance release contains new features and fixes several known issues.
+Couchbase Server 7.6.2 was released in July 2024. This maintenance release contains new features and fixes several known issues.
 
 For detailed information on new features and enhancements, please see xref:introduction:whats-new.adoc[].
 
@@ -101,8 +101,11 @@ The value could also show as being greater than 100%, as it did not account for
 | Added `kv_vb_ht_avg_size` and `kv_vb_ht_max_size` which summarizes the current HT sizes across vBuckets.
 
 | https://issues.couchbase.com/browse/MB-61525[MB-61525]
-| when a Consumer node enters an OOM phase, the `DCP Consumer` starts buffering incoming messaged into Checkpoints. For those messages we don't, (and we can't) enforce the CheckpointQuota by design, as consumers are allowed to process and buffer DCP messages up to limits defined by the `dcp_consumer_buffer_ratio` config param.
-| We now expose the real `checkpoint mem-usage` limit, which is `(checkpoint_memory_ratio + dcp_consumer_buffer_ratio)`.
+| With the removal of the dedicated DCP consumer buffer in 7.6.0 in a temporary out-of-memory scenario, a consumer node could continue to consume DCP mutations and add to the checkpoint beyond the allocated checkpoint memory quota. This is limited by the dcp consumer buffer quota.
+| A new metric has been added to track the sum of the checkpoint quota and the DCP consumer buffer quota. This is used to make
+sure the memcached
+ memory allocation on a consumer node isn't exceeding the allocated memory quotas: +
+`checkpoint_mem-usage` limit = `checkpoint_memory_ratio` + `dcp_consumer_buffer_ratio`.
 
 |===
 
@@ -130,14 +133,21 @@ The value could also show as being greater than 100%, as it did not account for
 
 
 | https://issues.couchbase.com/browse/MB-61043[MB-61043]
-| A skewed cluster won't be corrected because we early exit rebalance if there is no topology change, and there are no missing actives or replicas.
-| Now, the system updates the `rebalance early exit code` to check for such a skewed partition count.
+| In scenarios where a rebalance is followed by a failover, the partitions are not evenly distributed across all nodes, causing a skewness.
+| Skewness has been resolved.
 
 | https://issues.couchbase.com/browse/MB-61310[MB-61310]
 | During rebalance, when moving partitions around, we track the progress of movement and then check the seq numbers the partition has  caught up relative to the view of the partition on source node and also the `KV`’s view. +
 This progress monitoring procedure  was only for active partitions
 | You can now optionally monitor the replicas as well
 
+| https://issues.couchbase.com/browse/MB-61654[MB-61654]
+| Prometheus fails to scrape the new `xattrs` fields)
+| Problem caused by the use of `*num_vectors` which uses Prometheus-reserved character; `num_vectors` will no longer show up in
+ the stats.
+
+
+
 |===
 
 ==== Tools