diff --git a/content/vault/v1.20.x/content/docs/internals/telemetry/metrics/all.mdx b/content/vault/v1.20.x/content/docs/internals/telemetry/metrics/all.mdx
index 500f34b20c..f58684c623 100644
--- a/content/vault/v1.20.x/content/docs/internals/telemetry/metrics/all.mdx
+++ b/content/vault/v1.20.x/content/docs/internals/telemetry/metrics/all.mdx
@@ -188,6 +188,8 @@ alphabetic order by name.
 
 @include 'telemetry-metrics/vault/core/in_flight_requests.mdx'
 
+@include 'telemetry-metrics/vault/core/response_status_code.mdx'
+
 @include 'telemetry-metrics/vault/core/leadership_lost.mdx'
 
 @include 'telemetry-metrics/vault/core/leadership_setup_failed.mdx'
diff --git a/content/vault/v1.21.x (rc)/content/docs/agent-and-proxy/proxy/caching/static-secret-caching.mdx b/content/vault/v1.21.x (rc)/content/docs/agent-and-proxy/proxy/caching/static-secret-caching.mdx
index 61be100b10..cf704dec60 100644
--- a/content/vault/v1.21.x (rc)/content/docs/agent-and-proxy/proxy/caching/static-secret-caching.mdx	
+++ b/content/vault/v1.21.x (rc)/content/docs/agent-and-proxy/proxy/caching/static-secret-caching.mdx	
@@ -18,13 +18,22 @@ feature for cache freshness. As a result, static secret caching can only be used
 with Vault Enterprise installations.
 
 When using a Vault cluster with performance standbys, Proxy may receive secret update events
-before the secret update has been fully replicated. To make sure that Proxy can get updated
-secret values after receiving an event notification, Proxy must be configured to point to the
-address of the active node in its [Vault stanza](/vault/docs/agent-and-proxy/proxy#vault-stanza),
-or [allow_forwarding_via_header must be set to true](/vault/docs/configuration/replication#allow_forwarding_via_header)
-on the cluster. When `allow_forwarding_via_header` is configured, Proxy will only forward
-requests to update a secret in its cache after receiving an event indicating that secret got updated.
-This approach would be recommended if access to Vault was behind, for example, a load balancer.
+before the secret update is fully replicated.
+
+When using Vault Proxy 1.21+ and Vault Server 1.20+, Vault Proxy handles the
+incomplete replication automatically with client-controlled consistency. If
+needed, Vault Proxy retries the read on any secondary node until the
+storage index for the corresponding secret update is present on the node.
+
+If you use Vault Proxy 1.20 or earlier and/or Vault 1.19 or earlier, to make
+sure that Proxy can get updated secret values after receiving an event notification, 
+Proxy must be configured to point to the address of the active node in its 
+[Vault stanza](/vault/docs/agent-and-proxy/proxy#vault-stanza), or 
+[`allow_forwarding_via_header`](/vault/docs/configuration/replication#allow_forwarding_via_header)
+must be set to `true` on the cluster. When `allow_forwarding_via_header` is configured, 
+Proxy will only forward requests to update a secret in its cache after receiving an
+event indicating that secret got updated. This approach would be recommended if access
+to Vault was behind, for example, a load balancer.
 
 ## Step 1: Subscribe Vault Proxy to KV events
 
diff --git a/content/vault/v1.21.x (rc)/content/docs/internals/telemetry/metrics/all.mdx b/content/vault/v1.21.x (rc)/content/docs/internals/telemetry/metrics/all.mdx
index acac06d10c..fa00634e3d 100644
--- a/content/vault/v1.21.x (rc)/content/docs/internals/telemetry/metrics/all.mdx	
+++ b/content/vault/v1.21.x (rc)/content/docs/internals/telemetry/metrics/all.mdx	
@@ -188,6 +188,8 @@ alphabetic order by name.
 
 @include 'telemetry-metrics/vault/core/in_flight_requests.mdx'
 
+@include 'telemetry-metrics/vault/core/response_status_code.mdx'
+
 @include 'telemetry-metrics/vault/core/leadership_lost.mdx'
 
 @include 'telemetry-metrics/vault/core/leadership_setup_failed.mdx'